From teddy at recompile.se Fri Jun 1 21:22:40 2012 From: teddy at recompile.se (Teddy Hogeborn) Date: Fri, 01 Jun 2012 21:22:40 +0200 Subject: Version 1.5.5 of Mandos is released Message-ID: <87d35in8fz.fsf@tower.recompile.se> Version 1.5.5 of Mandos is released. This is minor bug fix release, but also includes a minor new feature. Version 1.5.5 (2012-06-01) * Server ** Server takes new --socket option Debian package changes: * debian/copyright (Format): Updated to "http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/". * debian/control (Build-Depends): Removed "man, locales-all". (Standards-Version): Updated to "3.9.3". This release also eliminates the "pointer-cast-size-mismatch" warning From the Buildd Log Scanner: The Debian package for unstable can be found on mentors.debian.net: - dget http://mentors.debian.net/debian/pool/main/m/mandos/mandos_1.5.5-1.dsc /Teddy Hogeborn & Bj?rn P?hlsson -- The Mandos Project http://www.recompile.se/mandos -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From dick at fouter.net Sun Jun 3 19:18:21 2012 From: dick at fouter.net (Dick Middleton) Date: Sun, 03 Jun 2012 18:18:21 +0100 Subject: Startup troubles Message-ID: <4FCB9C5D.8070804@fouter.net> Hi, I'm having trouble getting this thing to work. I'm using Debian squeeze i386 on the server and Debian Wheezy amd64 on the client. On the server I've updated mandos to 1.5.4 to match the client version. Firstly is there not a HOWTO guide for setting this up? I've created a client section for the server using mandos-keygen --password I'm then trying to test using /usr/lib/mandos/plugins.d/mandos-client --pubkey.... etc as in DEADME.Debian On the server the following message is seen: Jun 3 16:55:20 hagrid ???<28>Mandos [28204]: WARNING: Handshake failed: An algorithm that is not enabled was negotiated. That doesn't mean much to me; is it important? Incidentally why is the program name given to logger "???<28>Mandos"? On the client I get: Mandos plugin mandos-client: scandir: No such file or directory Again I don't know what's missing and whether it's important. All I know is no password is returned. It just sits and waits. Looking at debug client is reporting: Mandos plugin mandos-client: *** GnuTLS Handshake failed *** GnuTLS error: A TLS packet with unexpected length was received. Apart from the Handshake error above the server seems happy. Some guidance for what to do next would be appreciated. OK now, I need 2 passphrases for my client. One for the root disc and one for the hibernate partition. Is this supported? Do I just need two sections, one for each passphrase? If I use the -n option on mandos-keygen --password it not only changes the section name it also changes the host name. Is that right? Many thanks Dick From dick at fouter.net Sun Jun 3 21:25:39 2012 From: dick at fouter.net (Dick Middleton) Date: Sun, 03 Jun 2012 20:25:39 +0100 Subject: Startup troubles In-Reply-To: <4FCB9C5D.8070804@fouter.net> References: <4FCB9C5D.8070804@fouter.net> Message-ID: <4FCBBA33.8010708@fouter.net> On 06/03/12 18:18, Dick Middleton wrote: > Jun 3 16:55:20 hagrid ???<28>Mandos [28204]: WARNING: Handshake failed: An > algorithm that is not enabled was negotiated. > All I know is no password is returned. It just sits and waits. > > Looking at debug client is reporting: > Mandos plugin mandos-client: *** GnuTLS Handshake failed *** > GnuTLS error: A TLS packet with unexpected length was received. I tried generating RSA keys instead of the default DSA keys and it works now. I still get the Mandos plugin mandos-client: scandir: No such file or directory on the client but I guess that's unrelated. Is it due to /etc/mandos/plugin.d directory being empty? Dick From teddy at recompile.se Tue Jun 5 19:11:38 2012 From: teddy at recompile.se (Teddy Hogeborn) Date: Tue, 05 Jun 2012 19:11:38 +0200 Subject: Startup troubles In-Reply-To: <4FCB9C5D.8070804@fouter.net> (Dick Middleton's message of "Sun, 03 Jun 2012 18:18:21 +0100") References: <4FCB9C5D.8070804@fouter.net> Message-ID: <87pq9d4rat.fsf@tower.recompile.se> Dick Middleton writes: > I'm having trouble getting this thing to work. I'm using Debian > squeeze i386 on the server and Debian Wheezy amd64 on the client. On > the server I've updated mandos to 1.5.4 to match the client version. Sorry, could not reproduce your problem on same setup here. > Firstly is there not a HOWTO guide for setting this up? The README.Debian files contain the most direct instructions. > I've created a client section for the server using mandos-keygen > --password > > I'm then trying to test using /usr/lib/mandos/plugins.d/mandos-client > --pubkey.... etc as in README.Debian Yes, that should work. > On the server the following message is seen: > > Jun 3 16:55:20 hagrid ???<28>Mandos [28204]: WARNING: Handshake failed: An > algorithm that is not enabled was negotiated. > > That doesn't mean much to me; is it important? Yes. The handshake should not fail. This is the major problem preventing Mandos from working. WHY the handshake fails is another matter, and I have no answer to that question. > Incidentally why is the program name given to logger "???<28>Mandos"? It isn't; from the server source code (version 1.5.5, lines 119-121): syslogger.setFormatter(logging.Formatter ('Mandos [%(process)d]: %(levelname)s:' '%(message)s')) These odd junk characters could be indicative of some deeper problem with your system. > On the client I get: > > Mandos plugin mandos-client: scandir: No such file or directory > > Again I don't know what's missing and whether it's important. That's harmless and normal when running the client outside the initramfs environment. (The directory it fails to find is the network-hooks.d directory, and if you had configured any network hooks you probably wouldn't want them to run outside the initramfs environment anyway.) > All I know is no password is returned. It just sits and waits. > > Looking at debug client is reporting: > Mandos plugin mandos-client: *** GnuTLS Handshake failed *** > GnuTLS error: A TLS packet with unexpected length was received. > > Apart from the Handshake error above the server seems happy. The handshake is the problem, but it works on our setup. > Some guidance for what to do next would be appreciated. I would suggest filing a Debian bug using the "reportbug" tool - this will let us know what versions of libraries you have and many other details which might be helpful. > OK now, I need 2 passphrases for my client. One for the root disc and > one for the hibernate partition. Is this supported? Not really - it might work, but we haven't tested it. > Do I just need two sections, one for each passphrase? I would instead suggest using Mandos for the root partition password and then using a password file as the third field of crypttab for any subsequent encrypted partitions needed for booting. The password file(s) should of course be appropriately secured by file permissions and located on the root partition. > If I use the -n option on mandos-keygen --password it not only changes > the section name it also changes the host name. Is that right? Is does, yes. However, that doesn't really affect anything - the name in the OpenPGP key is not used for anything, and the host name can be changed in clients.conf with no ill effects. /Teddy Hogebort -- The Mandos Project http://www.recompile.se/mandos -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From teddy at recompile.se Tue Jun 5 19:24:54 2012 From: teddy at recompile.se (Teddy Hogeborn) Date: Tue, 05 Jun 2012 19:24:54 +0200 Subject: Startup troubles In-Reply-To: <4FCBBA33.8010708@fouter.net> (Dick Middleton's message of "Sun, 03 Jun 2012 20:25:39 +0100") References: <4FCB9C5D.8070804@fouter.net> <4FCBBA33.8010708@fouter.net> Message-ID: <87ipf54qop.fsf@tower.recompile.se> Dick Middleton writes: > > Jun 3 16:55:20 hagrid ???<28>Mandos [28204]: WARNING: Handshake > > failed: An algorithm that is not enabled was negotiated. > > > All I know is no password is returned. It just sits and waits. > > > > Looking at debug client is reporting: > > Mandos plugin mandos-client: *** GnuTLS Handshake failed *** > > GnuTLS error: A TLS packet with unexpected length was received. > > I tried generating RSA keys instead of the default DSA keys and it > works now. Right. That definitely points to GnuTLS having problems. Can the gnutls-cli command connect to a running gnutls-serv? Does gnutls-serv handle the --priority "SECURE256:!CTYPE-X.509:+CTYPE-OPENPGP" option? If not - then this is a GnuTLS problem, not ours. Might you have altered the priority string of the Mandos server in mandos.conf? > I still get the > > Mandos plugin mandos-client: scandir: No such file or directory > > on the client but I guess that's unrelated. Is it due to > /etc/mandos/plugin.d directory being empty? You shouldn't get the error while booting, only when running the Mandos client outside the initramfs environment. (The directory it tries to scan is the network hook directory, which it won't find outside the initramfs environment.) /Teddy Hogeborn -- The Mandos Project http://www.recompile.se/mandos From dick at fouter.net Tue Jun 5 22:07:21 2012 From: dick at fouter.net (Dick Middleton) Date: Tue, 05 Jun 2012 21:07:21 +0100 Subject: Startup troubles In-Reply-To: <87ipf54qop.fsf@tower.recompile.se> References: <4FCB9C5D.8070804@fouter.net> <4FCBBA33.8010708@fouter.net> <87ipf54qop.fsf@tower.recompile.se> Message-ID: <4FCE66F9.4070708@fouter.net> On 06/05/12 18:24, Teddy Hogeborn wrote: Thanks for your answers. I can see that the only significant problem is gnutls. >> I tried generating RSA keys instead of the default DSA keys and it >> works now. > > Right. That definitely points to GnuTLS having problems. Can the > gnutls-cli command connect to a running gnutls-serv? Does gnutls-serv > handle the --priority "SECURE256:!CTYPE-X.509:+CTYPE-OPENPGP" option? I can't get these utilities to talk. That is almost certainly because I have no idea what I'm doing :-( gnutls-serv accepts the --priority option without complaint. Is that the only option I need? On the client side I'm just passing the mandos key files: --pgpcertfile /etc/keys/mandos/pubkey.txt --pgpkeyfile /etc/keys/mandos/seckey.txt but they don't complete the handshake. Error: Could not negotiate a supported cipher suite I'm guessing I need to set other options to do this. > If not - then this is a GnuTLS problem, not ours. > Might you have altered the priority string of the Mandos server in > mandos.conf? No. It's commented out. Another question. What happens after timeout expires (client disappears)? Does the server just disable the client i.e. can it be re-enabled with mandos-cli? I'm using this on a workstation rather than server so it disappears often for indefinite periods. Can the timeout/checking be disabled? Dick From teddy at recompile.se Tue Jun 5 23:07:02 2012 From: teddy at recompile.se (Teddy Hogeborn) Date: Tue, 05 Jun 2012 23:07:02 +0200 Subject: Startup troubles In-Reply-To: <4FCE66F9.4070708@fouter.net> (Dick Middleton's message of "Tue, 05 Jun 2012 21:07:21 +0100") References: <4FCB9C5D.8070804@fouter.net> <4FCBBA33.8010708@fouter.net> <87ipf54qop.fsf@tower.recompile.se> <4FCE66F9.4070708@fouter.net> Message-ID: <877gvl4geh.fsf@tower.recompile.se> Dick Middleton writes: > > Can the gnutls-cli command connect to a running gnutls-serv? Does > > gnutls-serv handle the --priority > > "SECURE256:!CTYPE-X.509:+CTYPE-OPENPGP" option? > > I can't get these utilities to talk. That is almost certainly because > I have no idea what I'm doing :-( > > gnutls-serv accepts the --priority option without complaint. Is that > the only option I need? > > On the client side I'm just passing the mandos key files: > > --pgpcertfile /etc/keys/mandos/pubkey.txt > --pgpkeyfile /etc/keys/mandos/seckey.txt No, the server side needs the keys. The client side needs only --priority "SECURE256:..." and also maybe "--insecure". Please note: To duplicate the situation exactly, the "gnutls-serv" command should be run on the Mandos *client*, and the "gnutls-cli" command should be run on the Mandos *server*. (It is a bit counter-intuitive, but we designed it that way; the Mandos server and Mandos client runs the TLS protocol "backwards" so the Mandos client could have certificates and the Mandos server wouldn't need them.) > but they don't complete the handshake. > Error: Could not negotiate a supported cipher suite That's odd. It works here. > I'm guessing I need to set other options to do this. No, that should work. > Another question. What happens after timeout expires (client > disappears)? > Does the server just disable the client Yes. > i.e. can it be re-enabled with mandos-cli? Yes. You can do it interactively using "mandos-monitor", use "mandos-cli --enable" from the command line or a script, or use the D-Bus interface to access the Client object and either set the "Enabled" property to "True" or call the "Enable()" method. > I'm using this on a workstation rather than server so it disappears > often for indefinite periods. Can the timeout/checking be disabled? Yes; set the "checker" option for the client in clients.conf to ":" or "true". Since ":" and "true" are shell commands that always succeed, this will make the checker always succeed, and the timeout will never time out. /Teddy Hogeborn -- The Mandos Project http://www.recompile.se/mandos -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From dick at fouter.net Wed Jun 6 00:22:52 2012 From: dick at fouter.net (Dick Middleton) Date: Tue, 05 Jun 2012 23:22:52 +0100 Subject: Startup troubles In-Reply-To: <877gvl4geh.fsf@tower.recompile.se> References: <4FCB9C5D.8070804@fouter.net> <4FCBBA33.8010708@fouter.net> <87ipf54qop.fsf@tower.recompile.se> <4FCE66F9.4070708@fouter.net> <877gvl4geh.fsf@tower.recompile.se> Message-ID: <4FCE86BC.40602@fouter.net> On 06/05/12 22:07, Teddy Hogeborn wrote: > Please note: To duplicate the situation exactly, the "gnutls-serv" > command should be run on the Mandos *client*, and the "gnutls-cli" > command should be run on the Mandos *server*. (It is a bit > counter-intuitive, but we designed it that way; the Mandos server and > Mandos client runs the TLS protocol "backwards" so the Mandos client > could have certificates and the Mandos server wouldn't need them.) > OK, some progress. I needed the --priority on both sides. So now I can succeed with the RSA key. The DSA key fails though, as when using mandos. The error reported on the client side gnutls-serv is: Error in handshake Error: Public key signing has failed. This is in the gnutls-serv debug output: |<3>| HSK[0x8548ff0]: Selected cipher suite: DHE_DSS_AES_256_CBC_SHA256 |<3>| HSK[0x8548ff0]: Selected Compression Method: NULL |<3>| HSK[0x8548ff0]: Safe renegotiation succeeded |<3>| EXT[0x8548ff0]: Sending extension CERT TYPE (1 bytes) |<3>| EXT[0x8548ff0]: Sending extension SAFE RENEGOTIATION (1 bytes) |<3>| HSK[0x8548ff0]: SessionID: c4d6d52f970e10171fdb9f56ee1b7a21f02773263546337888cddf573a9d6162 |<3>| HSK[0x8548ff0]: SERVER HELLO was queued [86 bytes] |<3>| HSK[0x8548ff0]: CERTIFICATE was queued [1617 bytes] |<3>| HSK[0x8548ff0]: signing handshake data: using DSA-SHA1 |<2>| ASSERT: privkey.c:1174 |<2>| ASSERT: pk.c:433 |<2>| Security level of algorithm requires hash SHA256(32) or better It's not clear to me if there's an error there or if that's normal. Any idea what's going wrong? Dick * Accepted connection from IPv4 192.168.46.7 port 40194 on Tue Jun 5 23:15:18 2012 |<2>| ASSERT: gnutls_constate.c:717 |<4>| REC[0x9469ff0]: Allocating epoch #1 |<2>| ASSERT: gnutls_buffers.c:974 |<4>| REC[0x9469ff0]: SSL 3.0 Handshake packet received. Epoch 0, length: 133 |<4>| REC[0x9469ff0]: Expected Packet Handshake(22) |<4>| REC[0x9469ff0]: Received Packet Handshake(22) with length: 133 |<4>| REC[0x9469ff0]: Decrypted Packet[0] Handshake(22) with length: 133 |<3>| HSK[0x9469ff0]: CLIENT HELLO was received. Length 129[129], frag offset 0, frag length: 129, sequence: 0 |<3>| HSK[0x9469ff0]: Client's version: 3.3 |<2>| ASSERT: gnutls_db.c:265 |<2>| ASSERT: gnutls_db.c:297 |<3>| EXT[0x9469ff0]: Parsing extension 'SERVER NAME/0' (21 bytes) |<3>| EXT[0x9469ff0]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes) |<3>| EXT[0x9469ff0]: Parsing extension 'CERT TYPE/9' (2 bytes) |<3>| HSK[0x9469ff0]: Selected certificate type OPENPGP (2) |<3>| EXT[0x9469ff0]: Parsing extension 'SIGNATURE ALGORITHMS/13' (2 bytes) |<3>| HSK[0x9469ff0]: Requested PK algorithm: RSA (1) -- ctype: OPENPGP (2) |<3>| HSK[0x9469ff0]: certificate[0] PK algorithm: DSA (2) - ctype: OPENPGP (2) |<3>| HSK[0x9469ff0]: Requested PK algorithm: RSA (1) -- ctype: OPENPGP (2) |<3>| HSK[0x9469ff0]: certificate[0] PK algorithm: DSA (2) - ctype: OPENPGP (2) |<3>| HSK[0x9469ff0]: Requested PK algorithm: RSA (1) -- ctype: OPENPGP (2) |<3>| HSK[0x9469ff0]: certificate[0] PK algorithm: DSA (2) - ctype: OPENPGP (2) |<3>| HSK[0x9469ff0]: Requested PK algorithm: RSA (1) -- ctype: OPENPGP (2) |<3>| HSK[0x9469ff0]: certificate[0] PK algorithm: DSA (2) - ctype: OPENPGP (2) |<3>| HSK[0x9469ff0]: Requested PK algorithm: RSA (1) -- ctype: OPENPGP (2) |<3>| HSK[0x9469ff0]: certificate[0] PK algorithm: DSA (2) - ctype: OPENPGP (2) |<3>| HSK[0x9469ff0]: Requested PK algorithm: RSA (1) -- ctype: OPENPGP (2) |<3>| HSK[0x9469ff0]: certificate[0] PK algorithm: DSA (2) - ctype: OPENPGP (2) |<3>| HSK[0x9469ff0]: Requested PK algorithm: RSA (1) -- ctype: OPENPGP (2) |<3>| HSK[0x9469ff0]: certificate[0] PK algorithm: DSA (2) - ctype: OPENPGP (2) |<3>| HSK[0x9469ff0]: Requested PK algorithm: DSA (2) -- ctype: OPENPGP (2) |<3>| HSK[0x9469ff0]: certificate[0] PK algorithm: DSA (2) - ctype: OPENPGP (2) |<3>| HSK[0x9469ff0]: Removing ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA384 |<3>| HSK[0x9469ff0]: Removing ciphersuite: ECDHE_ECDSA_AES_256_GCM_SHA384 |<3>| HSK[0x9469ff0]: Removing ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384 |<3>| HSK[0x9469ff0]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA256 |<3>| HSK[0x9469ff0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA256 (00.6A) |<3>| HSK[0x9469ff0]: Removing ciphersuite: RSA_AES_256_CBC_SHA256 |<3>| HSK[0x9469ff0]: Requested cipher suites[size: 46]: |<3>| 0x00, 0x6b DHE_RSA_AES_256_CBC_SHA256 |<3>| 0x00, 0x39 DHE_RSA_AES_256_CBC_SHA1 |<3>| 0x00, 0x88 DHE_RSA_CAMELLIA_256_CBC_SHA1 |<3>| 0x00, 0x67 DHE_RSA_AES_128_CBC_SHA256 |<3>| 0x00, 0x33 DHE_RSA_AES_128_CBC_SHA1 |<3>| 0x00, 0x45 DHE_RSA_CAMELLIA_128_CBC_SHA1 |<3>| 0x00, 0x16 DHE_RSA_3DES_EDE_CBC_SHA1 |<3>| 0x00, 0x6a DHE_DSS_AES_256_CBC_SHA256 |<3>| HSK[0x9469ff0]: Selected cipher suite: DHE_DSS_AES_256_CBC_SHA256 |<3>| HSK[0x9469ff0]: Selected Compression Method: NULL |<3>| HSK[0x9469ff0]: Safe renegotiation succeeded |<3>| EXT[0x9469ff0]: Sending extension CERT TYPE (1 bytes) |<3>| EXT[0x9469ff0]: Sending extension SAFE RENEGOTIATION (1 bytes) |<3>| HSK[0x9469ff0]: SessionID: b41a8d65dd4094c7a83f909e65841e927733b20c1624e1e63fbef8f0b00c44f7 |<3>| HSK[0x9469ff0]: SERVER HELLO was queued [86 bytes] |<3>| HSK[0x9469ff0]: CERTIFICATE was queued [1617 bytes] |<3>| HSK[0x9469ff0]: signing handshake data: using DSA-SHA1 |<2>| ASSERT: privkey.c:1174 |<2>| ASSERT: pk.c:433 |<2>| Security level of algorithm requires hash SHA256(32) or better |<2>| ASSERT: pk.c:443 |<2>| ASSERT: pk.c:455 |<2>| ASSERT: gnutls_sig.c:192 |<2>| ASSERT: privkey.c:1290 |<2>| ASSERT: gnutls_privkey.c:663 |<2>| ASSERT: gnutls_sig.c:159 |<2>| ASSERT: dhe.c:196 |<2>| ASSERT: gnutls_kx.c:186 |<2>| ASSERT: gnutls_handshake.c:2793 Error in handshake Error: Public key signing has failed. |<4>| REC: Sending Alert[2|80] - Internal error |<4>| REC[0x9469ff0]: Preparing Packet Alert(21) with length: 2 |<4>| REC[0x9469ff0]: Sent Packet[1] Alert(21) in epoch 0 and length: 7 |<2>| ASSERT: gnutls_record.c:238 |<4>| REC[0x9469ff0]: Start of epoch cleanup |<4>| REC[0x9469ff0]: End of epoch cleanup |<4>| REC[0x9469ff0]: Epoch #0 freed |<4>| REC[0x9469ff0]: Epoch #1 freed From teddy at recompile.se Wed Jun 6 00:36:08 2012 From: teddy at recompile.se (Teddy Hogeborn) Date: Wed, 06 Jun 2012 00:36:08 +0200 Subject: Startup troubles In-Reply-To: <4FCE86BC.40602@fouter.net> (Dick Middleton's message of "Tue, 05 Jun 2012 23:22:52 +0100") References: <4FCB9C5D.8070804@fouter.net> <4FCBBA33.8010708@fouter.net> <87ipf54qop.fsf@tower.recompile.se> <4FCE66F9.4070708@fouter.net> <877gvl4geh.fsf@tower.recompile.se> <4FCE86BC.40602@fouter.net> Message-ID: <87vcj51j53.fsf@tower.recompile.se> Dick Middleton writes: > So now I can succeed with the RSA key. The DSA key fails though, as > when using mandos. Huh. I strongly suggest you report this as a GnuTLS bug. In the mean time, you could either use RSA keys or experiment with the priority string; does adding ":!VERS-TLS1.2" help? I ask because there was an issue with that once: https://savannah.gnu.org/support/index.php?107623 > It's not clear to me if there's an error there or if that's normal. > > Any idea what's going wrong? Sorry, no idea. /Teddy Hogeborn -- The Mandos Project http://www.recompile.se/mandos -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From dick at fouter.net Wed Jun 6 15:30:49 2012 From: dick at fouter.net (Dick Middleton) Date: Wed, 06 Jun 2012 14:30:49 +0100 Subject: Startup troubles In-Reply-To: <87vcj51j53.fsf@tower.recompile.se> References: <4FCB9C5D.8070804@fouter.net> <4FCBBA33.8010708@fouter.net> <87ipf54qop.fsf@tower.recompile.se> <4FCE66F9.4070708@fouter.net> <877gvl4geh.fsf@tower.recompile.se> <4FCE86BC.40602@fouter.net> <87vcj51j53.fsf@tower.recompile.se> Message-ID: <4FCF5B89.9060103@fouter.net> On 06/05/12 23:36, Teddy Hogeborn wrote: >> Any idea what's going wrong? > > Sorry, no idea. That's 2 of us :-) What I have found is that your !VERS-TLS1.2 suggestion doesn't help. However when I use a key length of 1024 bits rather than 2048 for the DSA keys it does work. I have seen cautions about using long key lengths for DSA with TLS but it puzzles me that it's only me having problems with the mandos default settings. Oh well, I think I'll give up there. I'm not convinced it's a bug with gnutls, although I wouldn't rule it out, and mandos is working. Thanks for your help and support. Dick From erik at logtenberg.eu Wed Jun 6 15:39:33 2012 From: erik at logtenberg.eu (Erik Logtenberg) Date: Wed, 06 Jun 2012 15:39:33 +0200 Subject: Fedora support In-Reply-To: <8762bepqa4.fsf@tower.recompile.se> References: <4FBFA1AF.3090504@logtenberg.eu> <8762bepqa4.fsf@tower.recompile.se> Message-ID: <4FCF5D95.6070100@logtenberg.eu> >> Is there a way to get >> Mandos running with Fedora? > > Not at the moment, sorry. Fedora, in their infinite wisdom, decided to > reimplement, incompatibly, the Debian initramfs-tools system; they are > calling it "Dracut". Supporting Dracut does not seem, at a glance, to > be outside the realm of possibility, so we are slowly working on it. I would be willing to contribute if that would be appreciated. Is there anything specific that needs to be done? Erik. From teddy at recompile.se Thu Jun 7 15:40:34 2012 From: teddy at recompile.se (Teddy Hogeborn) Date: Thu, 07 Jun 2012 15:40:34 +0200 Subject: Startup troubles In-Reply-To: <4FCF5B89.9060103@fouter.net> (Dick Middleton's message of "Wed, 06 Jun 2012 14:30:49 +0100") References: <4FCB9C5D.8070804@fouter.net> <4FCBBA33.8010708@fouter.net> <87ipf54qop.fsf@tower.recompile.se> <4FCE66F9.4070708@fouter.net> <877gvl4geh.fsf@tower.recompile.se> <4FCE86BC.40602@fouter.net> <87vcj51j53.fsf@tower.recompile.se> <4FCF5B89.9060103@fouter.net> Message-ID: <87d35bw88d.fsf@tower.recompile.se> Dick Middleton writes: > What I have found is that your !VERS-TLS1.2 suggestion doesn't > help. However when I use a key length of 1024 bits rather than 2048 > for the DSA keys it does work. Very odd. I would run gnutls-serv and gnutls-cli, both with the "--debug 11" flag, save the output, and open a bug report to either the Debian libgnutls package, or directly to the GnuTLS bug tracker. (Also, I would recommend using RSA keys instead of DSA, as opposed to decreasing the key length.) > I have seen cautions about using long key lengths for DSA with TLS Yes, but that's only because, allegedly, the TLS standard is vague about what to do in that case. When both sides use GnuTLS it should not be an issue. > but it puzzles me that it's only me having problems with the mandos > default settings. Me too. It couldn't be your Via c7 haunting us again, would it? > Oh well, I think I'll give up there. I'm not convinced it's a bug with > gnutls, although I wouldn't rule it out, and mandos is working. Since the problem can be reproduced using only gnutls-serv and gnutls-cli, I'm leaning towards GnuTLS being the culprit here. /Teddy Hogeborn -- Systemadministrat?r p? Nordisk Media Utveckling AB https://www.nmugroup.com/ tel:040-304770 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From dick at fouter.net Thu Jun 7 17:08:43 2012 From: dick at fouter.net (Dick Middleton) Date: Thu, 07 Jun 2012 16:08:43 +0100 Subject: Startup troubles In-Reply-To: <87d35bw88d.fsf@tower.recompile.se> References: <4FCB9C5D.8070804@fouter.net> <4FCBBA33.8010708@fouter.net> <87ipf54qop.fsf@tower.recompile.se> <4FCE66F9.4070708@fouter.net> <877gvl4geh.fsf@tower.recompile.se> <4FCE86BC.40602@fouter.net> <87vcj51j53.fsf@tower.recompile.se> <4FCF5B89.9060103@fouter.net> <87d35bw88d.fsf@tower.recompile.se> Message-ID: <4FD0C3FB.9090100@fouter.net> On 06/07/12 14:40, Teddy Hogeborn wrote: > Me too. It couldn't be your Via c7 haunting us again, would it? You've got a better memory that me :-) No, C7 gathering dust. I use an HP Prolient Microserver now. Nice machine and with cashback offer outstanding value for money. It's amd64 1.3G dual core. My plan is to put mandos on a Raspberry-Pi and tuck it away somewhere. It'll boot the servers (not that that happens very often) as well. Any issues running on ARM? I'll find something ;-) Dick From teddy at recompile.se Mon Jun 18 00:51:30 2012 From: teddy at recompile.se (Teddy Hogeborn) Date: Mon, 18 Jun 2012 00:51:30 +0200 Subject: Version 1.6.0 of Mandos is released Message-ID: <87k3z5wo0d.fsf@tower.recompile.se> Version 1.6.0 of Mandos is released. This is mostly a major release, except for a very useful new client feature. NEWS file excerpt: Version 1.6.0 (2012-06-18) * Server ** Takes new --foreground option ** Init script supports new "status" action. * Client ** Now uses all interfaces by default; the --interface option can still be used to restrict it, and the argument to --interface (as well as the $DEVICE environment variable for the network hooks) is now a comma-separated list of interfaces to use. This change is backward-compatible except that the default client behavior now takes up *all* usable interfaces instead of just the first usable interface it happens to find. This should not affect normal usage. Debian package changes: * debian/copyright (Copyright): Join the two lines to a single line. * debian/mandos-client.README.Debian: Update to refer to the new location of the example network hooks, and the new feature of using all network interfaces. * debian/mandos-client.docs (network-hooks.d): Removed. * debian/mandos-client.examples (network-hooks.d): New. * debian/rules (binary-common): Added "dh_installexamples". (binary-common/dh_fixperms): Exclude new location of "network-hooks.d". The Debian package for unstable can be found on mentors.debian.net: - dget http://mentors.debian.net/debian/pool/main/m/mandos/mandos_1.6.0-1.dsc /Teddy Hogeborn & Bj?rn P?hlsson -- The Mandos Project http://www.recompile.se/mandos -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From dick at fouter.net Tue Jun 19 23:24:36 2012 From: dick at fouter.net (Dick Middleton) Date: Tue, 19 Jun 2012 22:24:36 +0100 Subject: Raspberry-pi Message-ID: <4FE0EE14.9070200@fouter.net> Hi, Just as a matter of interest I've been playing with my new Raspberry-pi computer. http://www.raspberrypi.org/ Mandos works just fine. You do have to use the just released wheezy beta because the standard squeeze version doesn't have ipv6 enabled in the kernel. R-pi is ideal for the task of supplying boot passphrases to servers as it's low cost, low power and small. Dick From dick at fouter.net Fri Jun 22 14:38:44 2012 From: dick at fouter.net (Dick Middleton) Date: Fri, 22 Jun 2012 13:38:44 +0100 Subject: Checker directive clients.conf Message-ID: <4FE46754.7010908@fouter.net> Hi, If I place the checker directive (checker = :) in a client-name section-header it doesn't work. It works OK in the default section. This is 1.5.5-1 on Debian arm. Dick -- Dick Middleton dick at fouter.net From teddy at recompile.se Fri Jun 22 21:06:37 2012 From: teddy at recompile.se (Teddy Hogeborn) Date: Fri, 22 Jun 2012 21:06:37 +0200 Subject: Checker directive clients.conf In-Reply-To: <4FE46754.7010908@fouter.net> (Dick Middleton's message of "Fri, 22 Jun 2012 13:38:44 +0100") References: <4FE46754.7010908@fouter.net> Message-ID: <87k3yzcgjm.fsf@tower.recompile.se> Dick Middleton writes: > If I place the checker directive (checker = :) in a client-name > section-header it doesn't work. It works OK in the default section. > > This is 1.5.5-1 on Debian arm. Huh, it works here; we are unable to reproduce the problem. 1. What *exactly* did you try? Please give us a minimal (fictionalized) example config file which triggers the non-working behavior. 2. What *exactly* happened? Did the checker value get set at all? Did you get a backtrace? What? If relevant, please give a log of the output from "mandos --debug" (including stderr output). /Teddy Hogeborn -- The Mandos Project http://www.recompile.se/mandos From dick at fouter.net Fri Jun 22 21:57:06 2012 From: dick at fouter.net (Dick Middleton) Date: Fri, 22 Jun 2012 20:57:06 +0100 Subject: Checker directive clients.conf In-Reply-To: <87k3yzcgjm.fsf@tower.recompile.se> References: <4FE46754.7010908@fouter.net> <87k3yzcgjm.fsf@tower.recompile.se> Message-ID: <4FE4CE12.1010002@fouter.net> On 06/22/12 20:06, Teddy Hogeborn wrote: > Dick Middleton writes: > >> If I place the checker directive (checker = :) in a client-name >> section-header it doesn't work. It works OK in the default section. >> >> This is 1.5.5-1 on Debian arm. > > Huh, it works here; we are unable to reproduce the problem. It doesn't surprise me. Sorry, I was a bit quick to pen. I thought I'd nailed the problem but apparently not. The symptom is the server keeps disabling my sections for no apparent reason. I've just checked again and the last checker update was 18:58 (it's now 20:20), the server was restarted at ~15:10 and sections last re-enabled at 16:35. The time it takes to disable seems arbitrary (sometimes minutes sometimes hours). Checker is set to 'true' in all sections and the clients have been up all day (not that that should matter). But that's not the only problem, it doesn't always enable the entries when server is started even though I've got restore = false and enable = true explicitly. And, and there is nothing in /var/lib/mandos - I think it should have clients.pickle or something. This is on my little 'raspberry pi' arm computer and I suspect all is somehow related to that. So, as you request I need to do a little more investigation (sigh :-( ) Dick From dick at fouter.net Sat Jun 23 00:53:18 2012 From: dick at fouter.net (Dick Middleton) Date: Fri, 22 Jun 2012 23:53:18 +0100 Subject: Checker directive - debug info Message-ID: <4FE4F75E.9090805@fouter.net> 2012-06-22 21:43:50,701 root [5013]: INFO: Checker for Geronimo-DSA succeeded 2012-06-22 21:43:50,722 root [5013]: INFO: Checker for Penguin-DSA succeeded 2012-06-22 21:45:50,678 root [5013]: INFO: Starting checker 'true' for Geronimo-DSA 2012-06-22 21:45:50,749 root [5013]: INFO: Starting checker 'true' for Penguin-DSA Traceback (most recent call last): File "/usr/sbin/mandos", line 1326, in start_checker r = Client.start_checker(self, *args, **kwargs) File "/usr/sbin/mandos", line 725, in start_checker pid, status = os.waitpid(self.checker.pid, os.WNOHANG) OSError: [Errno 10] No child processes 2012-06-22 21:45:50,817 root [5013]: INFO: Checker for Geronimo-DSA succeeded 2012-06-22 21:45:50,838 root [5013]: INFO: Checker for Penguin-DSA succeeded 2012-06-22 21:47:50,717 root [5013]: INFO: Starting checker 'true' for Geronimo-DSA 2012-06-22 21:47:50,792 root [5013]: INFO: Checker for Geronimo-DSA succeeded Penguin-DSA is disabled after that error. 15mins later Geronimo-DSA had same error. I notice too checking takes place every 2 mins, I thought default was 5min. This is debian testing so the shell is dash. I see no errors for the pickle file. Dick mandos.conf [DEFAULT] restore = False debuglevel = DEBUG debug = true clients.conf [DEFAULT] ;timeout = 1h ;interval = 5m ;checker = fping -q -- %%(host)s checker = true [Penguin-DSA] host = Penguin.lingbrae checker = true fingerprint = ** secret = ** enabled = yes [Geronimo-DSA] host = geronimo.lingbrae checker = true fingerprint = ** secret = ** enabled = yes From teddy at recompile.se Sat Jun 23 02:53:27 2012 From: teddy at recompile.se (Teddy Hogeborn) Date: Sat, 23 Jun 2012 02:53:27 +0200 Subject: Checker directive - debug info In-Reply-To: <4FE4F75E.9090805@fouter.net> (Dick Middleton's message of "Fri, 22 Jun 2012 23:53:18 +0100") References: <4FE4F75E.9090805@fouter.net> Message-ID: <874nq2df20.fsf@tower.recompile.se> Dick Middleton writes: Just a quick comment before I check your real bug report (which I will as soon as I can): > I notice too checking takes place every 2 mins, I thought default was > 5min. That changed in version 1.4.0; it's now 2 minutes checking interval with 5 minutes timeout. /Teddy Hogeborn -- The Mandos Project http://www.recompile.se/mandos -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From teddy at recompile.se Sat Jun 23 15:51:34 2012 From: teddy at recompile.se (Teddy Hogeborn) Date: Sat, 23 Jun 2012 15:51:34 +0200 Subject: Checker directive - debug info In-Reply-To: <4FE4F75E.9090805@fouter.net> (Dick Middleton's message of "Fri, 22 Jun 2012 23:53:18 +0100") References: <4FE4F75E.9090805@fouter.net> Message-ID: <878vfeb0gp.fsf@tower.recompile.se> Dick Middleton writes: > 2012-06-22 21:45:50,749 root [5013]: INFO: Starting checker 'true' for Penguin-DSA > Traceback (most recent call last): > File "/usr/sbin/mandos", line 1326, in start_checker > r = Client.start_checker(self, *args, **kwargs) > File "/usr/sbin/mandos", line 725, in start_checker > pid, status = os.waitpid(self.checker.pid, os.WNOHANG) > OSError: [Errno 10] No child processes See, that's odd. Twelve lines before that, a child process *was* started, as logged by the debug message. Even if the subprocess exited before this line, there ought to have been a zombie process with the exit status for waitpid() to read. So I don't see how this could ever happen. I've added code to check for this in the latest trunk, though. Still, the question is: Where did the child process go? > Penguin-DSA is disabled after that error. Yes, the exception causes the checking to stop altogether (fixed in trunk). > I see no errors for the pickle file. This, too, is odd, since we check and log any errors when saving the pickle file. /Teddy Hogeborn -- The Mandos Project http://www.recompile.se/mandos -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From dick at fouter.net Sat Jun 23 19:20:06 2012 From: dick at fouter.net (Dick Middleton) Date: Sat, 23 Jun 2012 18:20:06 +0100 Subject: Checker directive - debug info In-Reply-To: <871ul6av2s.fsf@tower.recompile.se> References: <4FE4F75E.9090805@fouter.net> <878vfeb0gp.fsf@tower.recompile.se> <4FE5D1D7.5000003@fouter.net> <871ul6av2s.fsf@tower.recompile.se> Message-ID: <4FE5FAC6.50109@fouter.net> On 06/23/12 16:47, Teddy Hogeborn wrote: > Dick Middleton writes: > > (Did you mean to reply to me only or did you intend for this to go to > the list?) Sorry, that was remiss of me. I was posting on mandos-dev. I'm not sure I'm subscribed to mandos maintainers. Might be a better place for this! > Something wicked is going on with that system, I think. I've just completed a reinstall on a new disk (as I trouble getting the other one booting again). I've installed mandos which has pulled in avahi, dbus and all the python libs etc. I was hoping all problems were going to evaporate as a result. Sadly it behaves exactly the same. 1. disables server section arbitrarily 2. doesn't create pickle file 3. puts funny characters in logger It does serve keys when they're enabled. The only other apps running are sshd and system stuff, there's loads of memory and swap. It all looks normal. I'm going to hack the logger bits out of mandos and create a test program. I'll let you know what happens! Dick From dick at fouter.net Sat Jun 23 20:34:15 2012 From: dick at fouter.net (Dick Middleton) Date: Sat, 23 Jun 2012 19:34:15 +0100 Subject: Checker directive - debug info In-Reply-To: <4FE5FAC6.50109@fouter.net> References: <4FE4F75E.9090805@fouter.net> <878vfeb0gp.fsf@tower.recompile.se> <4FE5D1D7.5000003@fouter.net> <871ul6av2s.fsf@tower.recompile.se> <4FE5FAC6.50109@fouter.net> Message-ID: <4FE60C27.1010505@fouter.net> On 06/23/12 18:20, Dick Middleton wrote: > 3. puts funny characters in logger > I'm going to hack the logger bits out of mandos and create a test program. > I'll let you know what happens! Item 3 seems to be to do with unicode_literals in the statement from __future__ import (division, absolute_import, print_function unicode_literals) I've no idea how that works but if I remove unicode_literals problem goes away. Dick -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mandos.hack URL: From dick at fouter.net Sat Jun 23 16:25:27 2012 From: dick at fouter.net (Dick Middleton) Date: Sat, 23 Jun 2012 15:25:27 +0100 Subject: Checker directive - debug info In-Reply-To: <878vfeb0gp.fsf@tower.recompile.se> References: <4FE4F75E.9090805@fouter.net> <878vfeb0gp.fsf@tower.recompile.se> Message-ID: <4FE5D1D7.5000003@fouter.net> On 06/23/12 14:51, Teddy Hogeborn wrote: > Dick Middleton writes: > >> 2012-06-22 21:45:50,749 root [5013]: INFO: Starting checker 'true' for Penguin-DSA >> Traceback (most recent call last): >> File "/usr/sbin/mandos", line 1326, in start_checker >> r = Client.start_checker(self, *args, **kwargs) >> File "/usr/sbin/mandos", line 725, in start_checker >> pid, status = os.waitpid(self.checker.pid, os.WNOHANG) >> OSError: [Errno 10] No child processes > > See, that's odd. Twelve lines before that, a child process *was* > started, as logged by the debug message. Even if the subprocess exited > before this line, there ought to have been a zombie process with the > exit status for waitpid() to read. So I don't see how this could ever > happen. I've added code to check for this in the latest trunk, though. > Still, the question is: Where did the child process go? I don't think I'd be changing code right now. There's something very peculiar about all this. I'm wondering if it's running out of memory or some other limitation. Unfortunately right now it's not working at all as it won't reboot after power-off. BTW I'm getting those funny characters prefixing 'Mandos' in syslog with this system too. That's two completely different systems and this is a brand new install. Could there be a python version compatibility error of some sort? Mandos is running 2.7 but 3.2 is installed too. Dick From teddy at recompile.se Sat Jun 23 17:47:55 2012 From: teddy at recompile.se (Teddy Hogeborn) Date: Sat, 23 Jun 2012 17:47:55 +0200 Subject: Checker directive - debug info In-Reply-To: <4FE5D1D7.5000003@fouter.net> (Dick Middleton's message of "Sat, 23 Jun 2012 15:25:27 +0100") References: <4FE4F75E.9090805@fouter.net> <878vfeb0gp.fsf@tower.recompile.se> <4FE5D1D7.5000003@fouter.net> Message-ID: <871ul6av2s.fsf@tower.recompile.se> Dick Middleton writes: (Did you mean to reply to me only or did you intend for this to go to the list?) > > > 2012-06-22 21:45:50,749 root [5013]: INFO: Starting checker 'true' for Penguin-DSA > > > Traceback (most recent call last): > > > File "/usr/sbin/mandos", line 1326, in start_checker > > > r = Client.start_checker(self, *args, **kwargs) > > > File "/usr/sbin/mandos", line 725, in start_checker > > > pid, status = os.waitpid(self.checker.pid, os.WNOHANG) > > > OSError: [Errno 10] No child processes > > > > See, that's odd. Twelve lines before that, a child process *was* > > started, as logged by the debug message. Even if the subprocess > > exited before this line, there ought to have been a zombie process > > with the exit status for waitpid() to read. So I don't see how this > > could ever happen. I've added code to check for this in the latest > > trunk, though. Still, the question is: Where did the child process > > go? > > I don't think I'd be changing code right now. There's something very > peculiar about all this. I agree completely. Very odd behavior all around. > I'm wondering if it's running out of memory or some other > limitation. Unfortunately right now it's not working at all as it > won't reboot after power-off. Something wicked is going on with that system, I think. > BTW I'm getting those funny characters prefixing 'Mandos' in syslog > with this system too. That's two completely different systems and > this is a brand new install. It boggles my mind. If the symptom could be reproduced outside the Mandos server, perhaps by writing a Python script which simply creates a logging object like the Mandos server does, then the bug could be handled by the Python people, which probably have more cross-platform debugging experience. > Could there be a python version compatibility error of some sort? > Mandos is running 2.7 but 3.2 is installed too. Mandos is written for 2.X; 3.X won't work. 2.7 should be fine. /Teddy Hogeborn -- The Mandos Project http://www.recompile.se/mandos From dick at fouter.net Sat Jun 23 22:34:54 2012 From: dick at fouter.net (Dick Middleton) Date: Sat, 23 Jun 2012 21:34:54 +0100 Subject: Checker directive - debug info In-Reply-To: <4FE60C27.1010505@fouter.net> References: <4FE4F75E.9090805@fouter.net> <878vfeb0gp.fsf@tower.recompile.se> <4FE5D1D7.5000003@fouter.net> <871ul6av2s.fsf@tower.recompile.se> <4FE5FAC6.50109@fouter.net> <4FE60C27.1010505@fouter.net> Message-ID: <4FE6286E.5090701@fouter.net> On 06/23/12 19:34, Dick Middleton wrote: > On 06/23/12 18:20, Dick Middleton wrote: > >> 3. puts funny characters in logger > >> I'm going to hack the logger bits out of mandos and create a test program. >> I'll let you know what happens! > > Item 3 seems to be to do with unicode_literals in the statement > > from __future__ import (division, absolute_import, print_function > unicode_literals) More info: It's not entirely gone away: Jun 23 19:18:20 rpi Mandos [2343]: INFO: Starting checker 'true' for Penguin-DSA Jun 23 19:18:20 rpi Mandos [2343]: INFO: Checker for Geronimo-DSA succeeded Jun 23 19:18:20 rpi Mandos [2343]: INFO: Checker for Penguin-DSA succeeded Jun 23 19:18:54 rpi ???Mandos [2391]: INFO: TCP connection from: ('fe80::20a:cdff:fe1c:7cd0%eth0', 43125, 0, 2) Jun 23 19:18:54 rpi Mandos [2391]: DEBUG: Pipe FD: 15 Jun 23 19:18:54 rpi Mandos [2391]: DEBUG: Protocol version: '1\r\n' Jun 23 19:18:54 rpi Mandos [2391]: DEBUG: Handshake succeeded The lines which do this pass explicitly unicode strings to logger e.g: logger.info("TCP connection from: %s", unicode(self.client_address)) Regarding 2. pickle file - I think I misunderstood; this file doesn't exist when mandos is running. Is that right? It's read and deleted then written again when mandos terminates. So it's probably been working all along. Regarding 3. > See, that's odd. Twelve lines before that, a child process *was* > started, as logged by the debug message. Even if the subprocess exited > before this line, there ought to have been a zombie process with the > exit status for waitpid() to read. So I don't see how this could ever > happen. I've added code to check for this in the latest trunk, though. "If anything just cannot go wrong, it will anyway." - Murphy's Law I replaced :/true with sleep 1 and it's still going strong. I think you're right it's a race condition. The test is completing before you can get to check for it. Probably aggravated by the very slow processor. That's enough for me today. At least it's not all a total mystery anymore. Thanks for your help Dick From teddy at recompile.se Sun Jun 24 04:01:23 2012 From: teddy at recompile.se (Teddy Hogeborn) Date: Sun, 24 Jun 2012 04:01:23 +0200 Subject: Checker directive - debug info In-Reply-To: <4FE6286E.5090701@fouter.net> (Dick Middleton's message of "Sat, 23 Jun 2012 21:34:54 +0100") References: <4FE4F75E.9090805@fouter.net> <878vfeb0gp.fsf@tower.recompile.se> <4FE5D1D7.5000003@fouter.net> <871ul6av2s.fsf@tower.recompile.se> <4FE5FAC6.50109@fouter.net> <4FE60C27.1010505@fouter.net> <4FE6286E.5090701@fouter.net> Message-ID: <871ul5a2oc.fsf@tower.recompile.se> Dick Middleton writes: > > > 3. puts funny characters in logger [...] > Jun 23 19:18:54 rpi ???Mandos [2391]: INFO: TCP connection from: > ('fe80::20a:cdff:fe1c:7cd0%eth0', 43125, 0, 2) Huh. On further investigation that turns out to be deliberate; those characters are the UTF-8 BOM. From logging/handlers.py: > # Treat unicode messages as required by RFC 5424 > if _unicode and type(msg) is unicode: > msg = msg.encode('utf-8') > if codecs: > msg = codecs.BOM_UTF8 + msg So, your syslog daemon doesn't seem to understand the RFC 5424 format. Also, neither does ours (rsyslog) - we can see the same characters in the log here. So I think we can chalk this one up to rsyslog not following RFC 5424 and move on. > Regarding 2. pickle file - I think I misunderstood; this file doesn't > exist when mandos is running. Is that right? Yes. > It's read and deleted then written again when mandos terminates. Yes. > So it's probably been working all along. Oh; well, that's good. :) > Regarding 3. > > > See, that's odd. Twelve lines before that, a child process *was* > > started, as logged by the debug message. Even if the subprocess > > exited before this line, there ought to have been a zombie process > > with the exit status for waitpid() to read. So I don't see how this > > could ever happen. I've added code to check for this in the latest > > trunk, though. > > "If anything just cannot go wrong, it will anyway." - Murphy's Law Yes; that's why I added code to handle that condition. But even in theory, that condition should be impossible, which is why we didn't originally check for it. > I replaced :/true with sleep 1 and it's still going strong. I think > you're right it's a race condition. The test is completing before you > can get to check for it. Probably aggravated by the very slow > processor. Yeah, but the thing is, the code doing the waitpid is there to cover for this exact race condition - in case the process completed before we could add the subprocess to the gobject event loop. When a process exits, a zombie should remain until waitpid() is called to get the exit status - that's what zombies are for. For waitpid to give ECHILD, this means there is no zombie - either no subprocess was started, or something else did waitpid() already; neither seems very likely. Now, if there is no subprocess at all after we just started a checker, what should we consider the checker result to be? /Teddy Hogeborn -- The Mandos Project http://www.recompile.se/mandos -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From dick at fouter.net Sun Jun 24 21:16:19 2012 From: dick at fouter.net (Dick Middleton) Date: Sun, 24 Jun 2012 20:16:19 +0100 Subject: Checker directive - debug info In-Reply-To: <871ul5a2oc.fsf@tower.recompile.se> References: <4FE4F75E.9090805@fouter.net> <878vfeb0gp.fsf@tower.recompile.se> <4FE5D1D7.5000003@fouter.net> <871ul6av2s.fsf@tower.recompile.se> <4FE5FAC6.50109@fouter.net> <4FE60C27.1010505@fouter.net> <4FE6286E.5090701@fouter.net> <871ul5a2oc.fsf@tower.recompile.se> Message-ID: <4FE76783.1090000@fouter.net> On 06/24/12 03:01, Teddy Hogeborn wrote: > Dick Middleton writes: > >>>> 3. puts funny characters in logger > So, your syslog daemon doesn't seem to understand the RFC 5424 format. > Also, neither does ours (rsyslog) - we can see the same characters in > the log here. So I think we can chalk this one up to rsyslog not > following RFC 5424 and move on. Googling around doesn't turn up much although it seems that the syslog protocol doesn't, or didn't until recently, support unicode. So no logger daemon would handle this correctly. Rsyslog seems to have some non-unicode character interpretation available as a stop-gap. I think my choice would be to not send unicode to the logger until it is supported. But then I speak English so it doesn't make any difference to me :-) > Yeah, but the thing is, the code doing the waitpid is there to cover for > this exact race condition - in case the process completed before we > could add the subprocess to the gobject event loop. When a process > exits, a zombie should remain until waitpid() is called to get the exit > status - that's what zombies are for. For waitpid to give ECHILD, this > means there is no zombie - either no subprocess was started, or > something else did waitpid() already; neither seems very likely. That should probably be investigated. > Now, if there is no subprocess at all after we just started a checker, > what should we consider the checker result to be? There's a thing! I suppose if there is no explanation forthcoming then one should use a retry mechanism. That seems a lot of work when the 'sleep 1' workaround is available. I think by preference I would introduce a check disable option somehow; the ':'/'true' solution spawns processes unnecessarily and so is not ideal. Anyway, we're a long way from "Something wicked is going on with that system,.." so that's good. I've got a workaround and you've got something to ponder. Thanks again for your support. It's been quite interesting, if a bit frustrating at times. Cheers Dick