Re: [users@httpd] HTTPD asking for password after power failure

[Yann Ylavic]

On Fri, Aug 12, 2016 at 9:31 PM, Christopher Schultz
 wrote:
>
> On 8/11/16 11:10 PM, Marat Khalili wrote:
>> From what I saw, this behavior of /dev/random is totally normal on
>> an idle Linux system.
>
> There seems to be some confusion about /dev/random on Linux systems.
> Yes, the behavior described here is normal: when the system comes up,
> there is very little entropy available on /dev/random. /dev/random
> needs random events to occur in order to provide that entropy, and
> those events are things like I/O interrupt timings, etc.

There is quickly not enough entropy when using /dev/random, and very
few (if any) interest in using it.

>
> IIRC, Linux relies on the keyboard to generate lots of those events
> and, on a server, the keyboard by definition doesn't get used. So
> other events are required to fill that entropy pool. So, after a
> reboot, the entropy pool is "shallow".

This is true after booting, but also each time /dev/random is (ab)used.

On the other hand, there is /dev/urandom, requiring 128bits of entropy
to be initialized (which are always there after the boot, except maybe
for specific embedded devices with no disk, hardly servers), plus a
few more entroy from time to (long) time, and is just as secure as
/dev/random (often the same implementation, certainly on Linux), while
never waiting/blocking for entropy...

>
> /dev/random is supposed to be a source of high-quality randomness
> /dev/urandom is supposed to be a source of low-quality randomness

This isn't true.

>
>> Just do not ever use /dev/random.

+1

>
> The choice of which to use is up to you, but remember that low-quality
> randomness gets you low-quality crypto keys. But to say that one
> should "not ever use /dev/random" is really bad advice.

If you really want to block and exhaust all entropy for the (few)
needs of /dev/urandom users, well you can use it, otherwise don't.


Regards,
Yann.

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] HTTPD asking for password after power failure

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

On 8/11/16 11:10 PM, Marat Khalili wrote:
> From what I saw, this behavior of /dev/random is totally normal on
> an idle Linux system.

There seems to be some confusion about /dev/random on Linux systems.
Yes, the behavior described here is normal: when the system comes up,
there is very little entropy available on /dev/random. /dev/random
needs random events to occur in order to provide that entropy, and
those events are things like I/O interrupt timings, etc.

IIRC, Linux relies on the keyboard to generate lots of those events
and, on a server, the keyboard by definition doesn't get used. So
other events are required to fill that entropy pool. So, after a
reboot, the entropy pool is "shallow".

/dev/random is supposed to be a source of high-quality randomness
/dev/urandom is supposed to be a source of low-quality randomness

> Just do not ever use /dev/random.

The choice of which to use is up to you, but remember that low-quality
randomness gets you low-quality crypto keys. But to say that one
should "not ever use /dev/random" is really bad advice.

- -chris

[1] https://en.wikipedia.org/wiki//dev/random#Linux

> --
> 
> With Best Regards, Marat Khalili
> 
> On July 30, 2016 6:04:42 AM GMT+03:00, Nick Williams 
>  wrote:
> 
> It took me a while to get back to this (it’s not a
> mission-critical server, but I have hit a point where I really do
> need to get it working again).
> 
> `apachectl restart` hung for many, many minutes without any input, 
> and I eventually quit it. I ran it again with `strace -Ff
> apachectl restart`. Towards the end it had read all of the vhost
> config files and opened up the request and error logs configured in
> them, and it read the media types config file:
> 
> [pid 22537] read(35, "# This file maps Internet media "..., 4096) =
> 4096
> 
> But after that is where things got weird:
> 
> [pid 22537] mmap(NULL, 8192, PROT_READ|PROT_WRITE, 
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f73aff27000 [pid 22537]
> open("/dev/random", O_RDONLY|O_CLOEXEC) = 35 [pid 22537] read(35, "
> p$\242\33\241", 1024) = 6 [pid 22537] read(35,
> "\205\31\345\274A\336", 1018) = 6 [pid 22537] read(35,
> "\335\16\7\370\343\311", 1012) = 6 [pid 22537] read(35,
> "\265\362\20}F\234", 1006) = 6 [pid 22537] read(35,
> "\223}\\\0+\242", 1000) = 6 [pid 22537] read(35,
> 
> Each `read` line there took about a full minute. It’s spending 
> FOREVER reading from /dev/random. That led me to try to read from 
> /dev/random, and it is only generating a byte every few seconds. I 
> don’t know why, but /dev/random appears to be borked on this
> machine.
> 
> I changed ssl-global.conf to use /dev/urandom instead of 
> /dev/random, and it started right up in a matter of seconds.
> 
> I know this is now off-topic, but does anyone know why /dev/random 
> would suddenly be gathering almost no entropy? I have never had
> this problem on this system before.
> 
> Thanks,
> 
> Nick
> 
>> On Jul 16, 2016, at 9:56 PM, Frank Gingras > > wrote:
>> 
>> Try to use apachectl restart instead to bypass your init
>> scripts. The latter are likely to hide actual errors that would
>> appear on STDERR.
>> 
>> If apachectl restart still gives you that error, perhaps your 
>> distro mangled it as well. Then, I would use strace with httpd
>> -X to get the complete picture.
>> 
>> On Sat, Jul 16, 2016 at 6:47 AM, Nicholas Williams 
>> > > wrote:
>> 
>> I have a server running OpenSUSE 42.1 with stock Apache HTTPD 2
>> installed from the package manager. It has been running without
>> issue for well over a year. We've restarted the service and the
>> server since then without issue. The service always starts  on
>> its own when the server boots.
>> 
>> Last night we had a power failure. The sever came up fine. All 
>> services, including MySQL, started fine. No obvious issues appear
>> anywhere. But HTTPD didn't start automatically. So I logged in to
>> the server to investigate and try to start it.
>> 
>> `service apache2 status` said FAILED with no details. 
>> `/var/log/apache2/error_log` showed nothing since the day before
>> the power failure.
>> 
>> `service apache2 start` hung for about 2 minutes, and then said
>> FAILED with no details. `/var/log/apache2/error_log` still showed
>> nothing since the day before the power failure. There was nothing
>> in the system log since my log-in to the server.
>> 
>> So I tried `strace -Ff service apache2 start`. The only thing I
>> see suspicious is it calls open on 
>> `/run/systemd/ask-password-block`. It appears it times out after
>> never receiving a password. But I have no idea why it would do
>> that. None of my SSL certificates have passphrases, and I've
>> always been able to start HTTPD without a password.
>> 
>> I'm at a loss here. Any suggestions?
>> 
>> Thanks,
>> 
>> Nick 
>> 

RE: [users@httpd] mod_proxy_fdpass.so file missing

[Houser, Rick]

With RPM, you don't ever want to modify the upstream source archive (instead 
you use patches or an external SPEC).  Rather than rebuilding the tarball and 
putting your SPEC inside it, you should be keeping the SPEC separate and using 
-bb or -ba (for a source RPM) argument to rpmbuild.


Rick Houser
Web Administration

> -Original Message-
> From: Ken Bell [mailto:kenb...@panix.com]
> Sent: Friday, August 12, 2016 02:19
> To: users@httpd.apache.org
> Subject: Re: [users@httpd] mod_proxy_fdpass.so file missing
> 
> This is on CentOS 6.8, but the error you show was the same.
> 
> To try to build the package I edited the httpd.spec file to add:
> "--enable-proxy" and "--enable-proxy-fdpass" to the "%configure"
> stanza. That got rid of the error you show but turned up a different
> one: "Installed (but unpackaged) file(s) found" regarding
> "/usr/lib64/httpd/modules/mod_proxy_hcheck.so".  I then added that
> file to the list of modules, recreated the "httpd-2.4.23.tar.bz"
> file and apparently successfully built the RPMs.
> 
> Ken
> 
> On Thu, 14 Jul 2016 03:15:27 GMT kohm...@iris.eonet.ne.jp wrote:
> >
> > During rpmbuild using httpd-2.4.23.tar.bz2, error message tells me
> > mod_proxy_fdpass.so is missing. This httpd-2.4.23.tar.bz2 was downloaded
> > from http://httpd.apache.org/download.cgi#apache24 at 12:00 JST on 7/14.
> >
> > Therefore, no httpd-2.4.20-1.x86_64.rpm is obtained.
> > It would be helpful httpd-2.4.23.tar.bz2 without error during rpmbuild
> > could be downloaded.
> >
> > CentOS Linux release 7.2.1511
> > kernel 3.10.0-327.22.2.el7.x86_64
> 
> --
> Ken Bell :: kenbell_AT_panix_DOT_com   :: 212-475-4976 (voice)
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] mod_proxy_fdpass.so file missing

[Ken Bell]

This is on CentOS 6.8, but the error you show was the same.

To try to build the package I edited the httpd.spec file to add:
"--enable-proxy" and "--enable-proxy-fdpass" to the "%configure"
stanza. That got rid of the error you show but turned up a different
one: "Installed (but unpackaged) file(s) found" regarding
"/usr/lib64/httpd/modules/mod_proxy_hcheck.so".  I then added that
file to the list of modules, recreated the "httpd-2.4.23.tar.bz"
file and apparently successfully built the RPMs.

Ken

On Thu, 14 Jul 2016 03:15:27 GMT kohm...@iris.eonet.ne.jp wrote:
>
> During rpmbuild using httpd-2.4.23.tar.bz2, error message tells me
> mod_proxy_fdpass.so is missing. This httpd-2.4.23.tar.bz2 was downloaded
> from http://httpd.apache.org/download.cgi#apache24 at 12:00 JST on 7/14.
>
> Therefore, no httpd-2.4.20-1.x86_64.rpm is obtained.
> It would be helpful httpd-2.4.23.tar.bz2 without error during rpmbuild
> could be downloaded.
>
> CentOS Linux release 7.2.1511
> kernel 3.10.0-327.22.2.el7.x86_64

-- 
Ken Bell :: kenbell_AT_panix_DOT_com   :: 212-475-4976 (voice)

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] HTTPD asking for password after power failure

[Marat Khalili]

>From what I saw, this behavior of /dev/random is totally normal on an idle 
>Linux system. Just do not ever use /dev/random.
-- 

With Best Regards,
Marat Khalili

On July 30, 2016 6:04:42 AM GMT+03:00, Nick Williams 
 wrote:
>It took me a while to get back to this (it’s not a mission-critical
>server, but I have hit a point where I really do need to get it working
>again).
>
>`apachectl restart` hung for many, many minutes without any input, and
>I eventually quit it. I ran it again with `strace -Ff apachectl
>restart`. Towards the end it had read all of the vhost config files and
>opened up the request and error logs configured in them, and it read
>the media types config file:
>
>[pid 22537] read(35, "# This file maps Internet media "..., 4096) =
>4096
>
>But after that is where things got weird:
>
>[pid 22537] mmap(NULL, 8192, PROT_READ|PROT_WRITE,
>MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f73aff27000
>[pid 22537] open("/dev/random", O_RDONLY|O_CLOEXEC) = 35
>[pid 22537] read(35, " p$\242\33\241", 1024) = 6
>[pid 22537] read(35, "\205\31\345\274A\336", 1018) = 6
>[pid 22537] read(35, "\335\16\7\370\343\311", 1012) = 6
>[pid 22537] read(35, "\265\362\20}F\234", 1006) = 6
>[pid 22537] read(35, "\223}\\\0+\242", 1000) = 6
>[pid 22537] read(35, 
>
>Each `read` line there took about a full minute. It’s spending FOREVER
>reading from /dev/random. That led me to try to read from /dev/random,
>and it is only generating a byte every few seconds. I don’t know why,
>but /dev/random appears to be borked on this machine.
>
>I changed ssl-global.conf to use /dev/urandom instead of /dev/random,
>and it started right up in a matter of seconds.
>
>I know this is now off-topic, but does anyone know why /dev/random
>would suddenly be gathering almost no entropy? I have never had this
>problem on this system before.
>
>Thanks,
>
>Nick
>
>> On Jul 16, 2016, at 9:56 PM, Frank Gingras  wrote:
>> 
>> Try to use apachectl restart instead to bypass your init scripts. The
>latter are likely to hide actual errors that would appear on STDERR.
>> 
>> If apachectl restart still gives you that error, perhaps your distro
>mangled it as well. Then, I would use strace with httpd -X to get the
>complete picture.
>> 
>> On Sat, Jul 16, 2016 at 6:47 AM, Nicholas Williams
>>
>wrote:
>> I have a server running OpenSUSE 42.1 with stock Apache HTTPD 2
>installed from the package manager. It has been running without issue
>for well over a year. We've restarted the service and the server since
>then without issue. The service always starts  on its own when the
>server boots.
>> 
>> Last night we had a power failure. The sever came up fine. All
>services, including MySQL, started fine. No obvious issues appear
>anywhere. But HTTPD didn't start automatically. So I logged in to the
>server to investigate and try to start it.
>> 
>> `service apache2 status` said FAILED with no details.
>`/var/log/apache2/error_log` showed nothing since the day before the
>power failure.
>> 
>> `service apache2 start` hung for about 2 minutes, and then said
>FAILED with no details. `/var/log/apache2/error_log` still showed
>nothing since the day before the power failure. There was nothing in
>the system log since my log-in to the server.
>> 
>> So I tried `strace -Ff service apache2 start`. The only thing I see
>suspicious is it calls open on `/run/systemd/ask-password-block`. It
>appears it times out after never receiving a password. But I have no
>idea why it would do that. None of my SSL certificates have
>passphrases, and I've always been able to start HTTPD without a
>password.
>> 
>> I'm at a loss here. Any suggestions?
>> 
>> Thanks,
>> 
>> Nick
>> -
>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>
>> For additional commands, e-mail: users-h...@httpd.apache.org
>
>> 
>>