From owner-freebsd-isp@FreeBSD.ORG Fri Jul 14 08:56:17 2006 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D137516A4E2 for ; Fri, 14 Jul 2006 08:56:17 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from wjv.com (fl-65-40-24-38.sta.embarqhsd.net [65.40.24.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41AEE43D45 for ; Fri, 14 Jul 2006 08:56:16 +0000 (GMT) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.13.6/8.13.1) with ESMTP id k6E8u4bQ039231; Fri, 14 Jul 2006 04:56:04 -0400 (EDT) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.13.6/8.13.1/Submit) id k6E8twHc039230; Fri, 14 Jul 2006 04:55:58 -0400 (EDT) (envelope-from bv) Date: Fri, 14 Jul 2006 04:55:58 -0400 From: Bill Vermillion To: "David J. Orman" Message-ID: <20060714085558.GB38905@wjv.com> References: <20060713160509.Y59264@pop.citytel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, J_CHICKENPOX_66,SPF_HELO_PASS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on bilver.wjv.com Cc: freebsd-isp@freebsd.org Subject: Re: Password file X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bv@wjv.com List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2006 08:56:17 -0000 On Thu, Jul 13, 2006 at 14:47 , the murky waters churned and seethed, the dark weeds parted and the water took on the sinister, shifting visage we recognize as David J. Orman. The great maw opened, and the following was heard: > 1 - SSH daemon changes in 4.11 would be my guess 2 - Changed > UID/GID for postfix user. You need to chown/chmod the spool > directory/contents properly using the new postfix user account > UID/GID 3 - No idea. > Your best bet is going to be reinstall, it'll be much less > painful IMO. Secondly, the way you are handling this, is bad. It > may have worked for a long time, but it's not the correct way to > go about this. I think a re-install is probably overkill. It shohld be nothing more than to see which programs are erroring, and then look at the UID/GID of directories and files. I only use sendmail - after it became more civilized back in about 1995 I moved from smail. So I don't know if postfix diddle the password files on reinstall, but I've see programs that do, so it's probably the UID/GID. He could change the directories/programs to match, or change the UID/GID in the new password file to match what they are. > #1 - You should not allow root login via ssh. You should ssh as > a normal user and su. This is for all cases, not just automated > processes. Bad bad bad. In a reply he said removing the user and adding the user fixed it. It might have been related to the stored key files and an remove/re-add would have nuked those files. > #2 - Although you didn't explain why, it *seems* as if you're > copying the master.passwd file/rebuilding your pwdb to make sure > user accounts are synched on the machines? If so - no comment, > other then stop right now. In this kind of deployment, where > you have multiple servers which need to have synchronized user > accounts, you need to setup some kind of directory server (LDAP > would be most common - OpenLDAP is a free LDAP server.) Then > your servers can do authentication via the LDAP store. Virtual > users in postfix can be handled the same way. And he really could edit the files if he took the proper steps. One would be to copy the file to a temporary spot on the new machine, and then run a diff on the files. At that point you know what is going to be changed. Secondly you backup the working password file [master.passwd] so you can put it back if things go wrong. Making sure you can reverse everything you do is the key to keeping systems up and running. And something I learned a long time ago when AT&T stupidly put in a ULIMIT of 1MB by default in their system, where we had to move login to login2, and write a login that set the ULIMIT to reasonable sizes, and then call login2, I learned the hard way to MAKE SURE that when you diddle critical files you always have at LEAST on more root login than the one you are using. Then when you make changes test by logging in on another account. And DO NOT log out your current root login. If you do that you may never get back in have to reinstall. I had remembered the extra login twice, but forgot it the 3rd time. This was an install over a Christmas Holiday, and we got shipped a wrong machine, and I was installing on the original with the idea to get much work done and then backup to tape, and transfer into the new machine when it arrived by overnight, shipping on Dec 26th. And in light if 'if anything can go wrong it will', it turns out when I made tape backups and verified them, the machine was writing NOTHING to tape, and the verify agreed with what it thought it had done. That was the conversion from hell. But if you know the system you should have no fear of editing virtually anything on the system, taking precautions to be able to reverse any changes - which includes making comments in all files you modify with time/date and intials/name. I've learned and have a degree from the School of Hard Knocks since I first migrated to Unix/Xenix systems back in 1983. In a Unix system which you know, only the worst cases - such as major file corruption - should ever require a re-install. > PS - I cannot strongly enough reiterate, the master.passwd > copying deal is *really* not the best way to do this, and remote > root logins are a bad idea. I agree 1000% on the remote root login, but as I stated, being careful and HOW you do it means you can edit your password files with no worry. However just copying without having any way to reverse your actions could be a recipe for disaster as the OP has found out. I've edited SysV password files, used vi to add fields to match the BSD formats, and took the shadow file from a SysV and inserted it into the master.passwd file, and moved the ISP I was working with then from and SGI IRIX environment onto FreeBSD. No problems. The plus was going from IRIX and the Netscape server to FreeBSD [I think it as 2.7 or so at that time] and moving from a 400Mhz MIPS to a 200Mhz Pentium - even with a slower CPU and about 1/2 the memory of the SGIs the performance was dramatically better. The real key is understand the Unix systems as a whole - and with that under your belt you can work on any variant you come across - if you know how to read error mesages and man pages. Bill -- Bill Vermillion - bv @ wjv . com