Re: Debian Woody - Sarge upgrade report
On Mon, May 16, 2005 at 11:21:12AM -0400, Roberto C. Sanchez wrote: Quoting Jonathan McDowell [EMAIL PROTECTED]: On Mon, May 16, 2005 at 09:27:23AM -0400, Roberto C. Sanchez wrote: Jonathan McDowell wrote: H. I run with my own CA signed cert and had no problems with a Woody - Sarge upgrade of sslwrap on Friday. Can you send me your /etc/sslwrap/debian_conf and the output of grep sslwrap /etc/inetd.conf (assuming you're running it from inetd)? Did you want to see what they looked like before or after the upgrade? Both, if possible. Whatever you've got easily would be a good start though. [both the same and as follows:] # grep sslwrap inetd.conf ssmtp stream tcp nowait root/usr/sbin/tcpd /usr/sbin/sslwrap -cert /etc/ssl/server_key_and_cert.pem -addr 127.0.0.1 -port 25 imaps stream tcp nowait root/usr/sbin/tcpd /usr/sbin/sslwrap -cert /etc/ssl/server_key_and_cert.pem -addr 127.0.0.1 -port 143 /etc/sslwrap/debian_config: run_mode=inetd used_addr=127.0.0.1 with_certificate=true certfile=/etc/ssl/server_key_and_cert.pem overwrite_corrupted_certfile=false check_cert=true ports=imaps, ssmtp I no longer have sslwrap installed since postfix-tls now properly grabs port 465 without dying and cyrus21 supports imaps (though last night I switched to courier, which also natively does imaps). Yes, these days sslwrap is thankfully not so necessary as applications are now able to link against the crypto code themselves. The problem, if you refer to my original mail, is that something about the CA was confusing sslwrap, which I believe tried to generate its own cert. Is your root cert installed into the openssl framework (ie plumbed into /etc/ssl/certs)? I think if that's not the case then as you have check_cert set to true it'll fail to be able to validate the cert. I'm surprised you haven't seen errors about this before on boot however. J. -- /-\ | Bother, said Pooh, Who put sand |@/ Debian GNU/Linux Developer |in the Vaseline?!?. \- | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Woody - Sarge upgrade report
Quoting Jonathan McDowell [EMAIL PROTECTED]: On Mon, May 16, 2005 at 11:21:12AM -0400, Roberto C. Sanchez wrote: The problem, if you refer to my original mail, is that something about the CA was confusing sslwrap, which I believe tried to generate its own cert. Is your root cert installed into the openssl framework (ie plumbed into /etc/ssl/certs)? I think if that's not the case then as you have check_cert set to true it'll fail to be able to validate the cert. I'm surprised you haven't seen errors about this before on boot however. No errors that I can see. My root cert is in /etc/ssl/demoCA. Everything seems to find it just fine. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Woody - Sarge upgrade report
On Fri, May 06, 2005 at 04:21:13PM -0400, Roberto C. Sanchez wrote: Last night (when I should have been working a project for my advanced algorithms class) I decided it was time to upgrade my personal server from Woody to Sarge. I am writing this email im the hopes that the release team and devs find it helpful and that other users who upgrade can make use of the information. In summary, here are the things that I saw: 4. sslwrap upgrade completely choked over openssl In detail: 4. The upgrade to sslwrap tried to generate an ssl certificate. For some reason (I suspect becuase I have created my own CA), openssl errored out, causing the sslwrap postinst to fail. This caused me repreated problems as it would hang up the postinst of other packages. I finally copied /etc/ssl and /etc/sslwrap off to another location, purge both openssl and sslwrap, reinstall both, remove /etc/ssl and /etc/sslwrap, and replace them with my backup copies. I am not sure why this happened, but I am pretty sure it is a bug. I have not yet filed a bug since I am not sure if it should go against openssl or sslwrap. Sugestions would be appreciated. H. I run with my own CA signed cert and had no problems with a Woody - Sarge upgrade of sslwrap on Friday. Can you send me your /etc/sslwrap/debian_conf and the output of grep sslwrap /etc/inetd.conf (assuming you're running it from inetd)? J. -- Revd. Jonathan McDowell, ULC | noodles is angry with him signature.asc Description: Digital signature
Re: Debian Woody - Sarge upgrade report
Jonathan McDowell wrote: H. I run with my own CA signed cert and had no problems with a Woody - Sarge upgrade of sslwrap on Friday. Can you send me your /etc/sslwrap/debian_conf and the output of grep sslwrap /etc/inetd.conf (assuming you're running it from inetd)? J. Did you want to see what they looked like before or after the upgrade? -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Re: Debian Woody - Sarge upgrade report
On Mon, May 16, 2005 at 09:27:23AM -0400, Roberto C. Sanchez wrote: Jonathan McDowell wrote: H. I run with my own CA signed cert and had no problems with a Woody - Sarge upgrade of sslwrap on Friday. Can you send me your /etc/sslwrap/debian_conf and the output of grep sslwrap /etc/inetd.conf (assuming you're running it from inetd)? Did you want to see what they looked like before or after the upgrade? Both, if possible. Whatever you've got easily would be a good start though. J. -- Web [ I don't bite. Well, that's wrong. I do bite. ] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.23 signature.asc Description: Digital signature
Re: Debian Woody - Sarge upgrade report
Quoting Jonathan McDowell [EMAIL PROTECTED]: On Mon, May 16, 2005 at 09:27:23AM -0400, Roberto C. Sanchez wrote: Jonathan McDowell wrote: H. I run with my own CA signed cert and had no problems with a Woody - Sarge upgrade of sslwrap on Friday. Can you send me your /etc/sslwrap/debian_conf and the output of grep sslwrap /etc/inetd.conf (assuming you're running it from inetd)? Did you want to see what they looked like before or after the upgrade? Both, if possible. Whatever you've got easily would be a good start though. J. ** BEGIN BEFORE ** # grep sslwrap inetd.conf ssmtp stream tcp nowait root/usr/sbin/tcpd /usr/sbin/sslwrap -cert /etc/ssl/server_key_and_cert.pem -addr 127.0.0.1 -port 25 imaps stream tcp nowait root/usr/sbin/tcpd /usr/sbin/sslwrap -cert /etc/ssl/server_key_and_cert.pem -addr 127.0.0.1 -port 143 /etc/sslwrap/debian_config: run_mode=inetd used_addr=127.0.0.1 with_certificate=true certfile=/etc/ssl/server_key_and_cert.pem overwrite_corrupted_certfile=false check_cert=true ports=imaps, ssmtp *** END BEFORE *** ** BEGIN AFTER ** # grep sslwrap inetd.conf ssmtp stream tcp nowait root/usr/sbin/tcpd /usr/sbin/sslwrap -cert /etc/ssl/server_key_and_cert.pem -addr 127.0.0.1 -port 25 imaps stream tcp nowait root/usr/sbin/tcpd /usr/sbin/sslwrap -cert /etc/ssl/server_key_and_cert.pem -addr 127.0.0.1 -port 143 /etc/sslwrap/debian_config: run_mode=inetd used_addr=127.0.0.1 with_certificate=true certfile=/etc/ssl/server_key_and_cert.pem overwrite_corrupted_certfile=false check_cert=true ports=imaps, ssmtp *** END AFTER *** I no longer have sslwrap installed since postfix-tls now properly grabs port 465 without dying and cyrus21 supports imaps (though last night I switched to courier, which also natively does imaps). The problem, if you refer to my original mail, is that something about the CA was confusing sslwrap, which I believe tried to generate its own cert. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Woody - Sarge upgrade report
Roberto C. Sanchez wrote: [SNIP] In summary, here are the things that I saw: 1. Dependency resolution was spectacular (who would expect less from Debian?) 2. New config files went OK. 3. Cyrus IMAP (going from cyrus v1.5 to cyrus21) broke very hard 4. sslwrap upgrade completely choked over openssl [SNIP] 3. I really have no idea what happened here. I carefully followed the upgrade instructions, but my mailboxes.db ended up corrupted, which caused the cyrus server to go crazy. Also, once I got saslauthd to where it would work correctly, cyrus refused all imap and imaps connections. I ended up having to go into /etc/hosts.allow and add ALL:LOCAL for cyrus to finally accept only local imap connections. I never figured out how to get it to accept imaps connections without adding ALL:ALL, which is not an acceptable solution). About 4 hours of Google searching yielded no useful information. I ended up setting impas to go through sslwrap (as I had for cyrus v1.5), since it would accept remote connections. I can't tell if this is a bug or a mis- configuration on my part. [SNIP] OK. I figured this out. The problem was misconfiguration on my part. However, I think the documentation was less than helpful. I had this in /etc/hosts.allow prior to upgrade: imapd: LOCAL Since cyrus in Woody was not ssl-enabled, I had sslwrap to proxy imaps. Here is the section from README.Debian in cyrus21-common: o The services are tcp-wrapped. Their hosts.allow/hosts.deny id is the service name in /etc/cyrus.conf. See hosts_access(5). I didn't quite understand and/or see this during the upgrade, but I ended up having to add LOCAL: ALL to /etc/hosts.allow (which I did not like). I finally figured this out after reading the README.Debian for about the fifth time yesterday. I don't think it is quite worthy of a bug report (maybe low priority, but then the change won't go into Sarge). However, I think that it should be more clearly stated that, e.g., if you HAD 'imapd' listed in hosts.allow, that it now becomes 'imap'. I consider myself an experienced user/admin and this little thing totally caught me off guard. Just my thoughts, -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Re: Debian Woody - Sarge upgrade report
Roberto C. Sanchez wrote: things about his woody-to-sarge transition I have made this transition a lot lately, too, and I would like to offer some insight about the following process: 2. The standard yes, no, diff, shell approach could probably use some tweaking. What I mean is that with so many config files being updated, there should be an option to manually merge now. This can be done in one of a couple of ways. A text editor could be opened with both the current and proposed config loaded (e.g., vim and emacs), or a single file could be presented with the diff'd In my experience, I almost always hit D (show differences), select the configfile name, :!vimdiff configfile(pasted from clipboard) configfile(idem).dpkg-new, do the merging, :diffupdate, :wq, hit D again, repeat if not satisfied, and then hit N (keep mine). In a woody-to-sarge dist-upgrade, this *really* hurts my wrists. What I would like is an option A (automerge) that did a 3-way merge of configfile and configfile.dpkg-new, open an editor in the conflict markers, let you edit the conflicts out, and when you save/exit, showed you the differences between your new configfile and configfile.dpkg-new, and asked again. portions inserted and marked in the complete file (e.g., editors that only support one open file). I think that this can be done by shelling out (with the Z option), but I am never really sure if my changes will stick. The option says shell to examine the situation, or something to that effect. There is no indication that if I change the config, the change will stick. Yeah, I feel unsafe, altough I *know* whatever I save in the configfile will stick. Also, some packages should adopt the policy of including a local snippet. What I mean is, for example, with the dhcpd package, or any package that requires a change to the config immediately after installation. Simply put, a dhcpd config will always need to be modified to tell which net, subnet mask, hostnames, MACs, and so on, it needs to handle. It is annoying when the messages throughout the file change and cause the admin to have to intervene in the process by choosing what to do. Some packages (e.g., horde2) have a config in /etc/pkg-name with a standard pkg-name.conf and then somewhere in the .conf file they source or include a snippet with the local changes. I encourage the maintainers of such packages (dhcpd and ntp, come to mind immediately) to consider this approach. I really agree with this. more stuff HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Woody - Sarge upgrade report
On 06-May-05, 15:21 (CDT), Roberto C. Sanchez [EMAIL PROTECTED] wrote: There is no indication that if I change the config, the change will stick. If you shell out, edit /etc/foo.conf to merge the updated from foo.conf.dpkg-new (or in any other way), then return to the conffile menu, then select 'N', your changes will be preserved. Simply put, a dhcpd config will always need to be modified to tell which net, subnet mask, hostnames, MACs, and so on, it needs to handle. Policy explicitly says that using the conffile mechanism is inappropriate for this kind of configuration file. Report a bug. Given that we have UCF, there's really no excuse for this any more. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
