Hi Folks,
I am doing a server swap out tomorrow and wondered if there was a utility that will copy user account details and their current passwords from one server to another (both CentOS 4) - there's only about 15 to do so it's not a major issue.
Thanks
Nigel Kendrick
On Wed, Nov 29, 2006 at 01:31:48PM -0000, Nigel Kendrick wrote:
I am doing a server swap out tomorrow and wondered if there was a utility that will copy user account details and their current passwords from one server to another (both CentOS 4) - there's only about 15 to do so it's not a major issue.
copy the relevant lines from /etc/passwd/, /etc/shadow, /etc/group, and /etc/gshadow. (Actually, you can almost certainly ignore the last, but for completeness.)
On Wed, Nov 29, 2006 at 01:31:48PM -0000, Nigel Kendrick said:
I am doing a server swap out tomorrow and wondered if there was a utility that will copy user account details and their current passwords from one server to another (both CentOS 4) - there's only about 15 to do so it's not a major issue.
Rsync and scp are your friend.
You can either cut and paste the user info from the /etc/passwd, shadow, and group files manually, or copy the entire files which wiill also copy over all the system accounts (root password and such):
cd /etc scp -p passwd shadow group newserver:/etc
Then of course you will probably need to copy the user home directories over:
cd /home rsync -aze ssh * newserver:/home
On Wednesday 29 November 2006 05:43, Walt Reed wrote:
On Wed, Nov 29, 2006 at 01:31:48PM -0000, Nigel Kendrick said:
I am doing a server swap out tomorrow and wondered if there was a utility that will copy user account details and their current passwords from one server to another (both CentOS 4) - there's only about 15 to do so it's not a major issue.
Rsync and scp are your friend.
You can either cut and paste the user info from the /etc/passwd, shadow, and group files manually, or copy the entire files which wiill also copy over all the system accounts (root password and such):
cd /etc scp -p passwd shadow group newserver:/etc
Then of course you will probably need to copy the user home directories over:
cd /home rsync -aze ssh * newserver:/home
It's worth noting that if you use external packages (rpmforge, kbsingh), that some packages may create users without a set UID (as the core packages seem to have), and if already installed on the new system, it might be using a different UID. In these cases, you should either copy regular user portions of the files only, or take a careful look at a diff between the old and new files to ensure there are no problems.
This caused me a few minutes of confusion with clamav/clamd (specifically the milter socket) which had an incorrect owner after passwd sync on a mail server migration.
On Wed, Nov 29, 2006 at 12:46:13PM -0800, Kevan Benson said:
On Wednesday 29 November 2006 05:43, Walt Reed wrote:
On Wed, Nov 29, 2006 at 01:31:48PM -0000, Nigel Kendrick said:
I am doing a server swap out tomorrow and wondered if there was a utility that will copy user account details and their current passwords from one server to another (both CentOS 4) - there's only about 15 to do so it's not a major issue.
Rsync and scp are your friend.
You can either cut and paste the user info from the /etc/passwd, shadow, and group files manually, or copy the entire files which wiill also copy over all the system accounts (root password and such):
cd /etc scp -p passwd shadow group newserver:/etc
Then of course you will probably need to copy the user home directories over:
cd /home rsync -aze ssh * newserver:/home
It's worth noting that if you use external packages (rpmforge, kbsingh), that some packages may create users without a set UID (as the core packages seem to have), and if already installed on the new system, it might be using a different UID. In these cases, you should either copy regular user portions of the files only, or take a careful look at a diff between the old and new files to ensure there are no problems.
This caused me a few minutes of confusion with clamav/clamd (specifically the milter socket) which had an incorrect owner after passwd sync on a mail server migration.
Ya, that is annoying.
When building the "replacement" server, it can help to sync / add accounts before all the third-party crap goes on. We do it as part of the kickstart %post scripts. Kickstart from pxe-boot is awesome - especially on HP servers... :-) Once a machine is installed in the rack and powered up for the first time, it's online and usable with all the packages we need, preconfigured, in about 15 minutes.
Walt Reed wrote:
On Wed, Nov 29, 2006 at 12:46:13PM -0800, Kevan Benson said:
On Wednesday 29 November 2006 05:43, Walt Reed wrote:
On Wed, Nov 29, 2006 at 01:31:48PM -0000, Nigel Kendrick said:
I am doing a server swap out tomorrow and wondered if there was a utility that will copy user account details and their current passwords from one server to another (both CentOS 4) - there's only about 15 to do so it's not a major issue.
Rsync and scp are your friend.
You can either cut and paste the user info from the /etc/passwd, shadow, and group files manually, or copy the entire files which wiill also copy over all the system accounts (root password and such):
cd /etc scp -p passwd shadow group newserver:/etc
Then of course you will probably need to copy the user home directories over:
cd /home rsync -aze ssh * newserver:/home
It's worth noting that if you use external packages (rpmforge, kbsingh), that some packages may create users without a set UID (as the core packages seem to have), and if already installed on the new system, it might be using a different UID. In these cases, you should either copy regular user portions of the files only, or take a careful look at a diff between the old and new files to ensure there are no problems.
This caused me a few minutes of confusion with clamav/clamd (specifically the milter socket) which had an incorrect owner after passwd sync on a mail server migration.
Ya, that is annoying.
When building the "replacement" server, it can help to sync / add accounts before all the third-party crap goes on. We do it as part of the kickstart %post scripts. Kickstart from pxe-boot is awesome - especially on HP servers... :-) Once a machine is installed in the rack and powered up for the first time, it's online and usable with all the packages we need, preconfigured, in about 15 minutes.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Walt - Can you show us your scripts?
I am working on something similar - a way to deploy a server using kickstart and then a handwritten script to configure things like postfix, ip, iptables, mysql, apache etc
I imagine however that all you clever people have already got this in your toolbox of tricks,.
Thanks,
MrKiwi
On Thu, Nov 30, 2006 at 10:49:37AM +1300, MrKiwi said:
Walt Reed wrote:
When building the "replacement" server, it can help to sync / add accounts before all the third-party crap goes on. We do it as part of the kickstart %post scripts. Kickstart from pxe-boot is awesome - especially on HP servers... :-) Once a machine is installed in the rack and powered up for the first time, it's online and usable with all the packages we need, preconfigured, in about 15 minutes.
Walt - Can you show us your scripts?
I am working on something similar - a way to deploy a server using kickstart and then a handwritten script to configure things like postfix, ip, iptables, mysql, apache etc
I imagine however that all you clever people have already got this in your toolbox of tricks,.
Well, obviously they are customized for our situation, and contain a lot of info about our infrastructure that I am not at liberty to divulge, but I can give you some pointers.
Critical to the whole process is setting up DHCP correctly, a tftp server, customizing the files in tftp so that the correct options are set for booting, setting up a local YUM repository, apache to serve the repository and kickstart files, etc. The kickstart script is almost trivial compared to all that. We also use an NFS server for many things.
Kickstart, in %post, runs:
/sbin/chkconfig to enable and disable all the services we need or don't need
Runs ntpdate and hwclock
Creates a bunch or directories in /usr/local and other areas, and mountpoints for various NFS / SAN filesystems
Adds the mount info to fstab
Starts portmapper
Mounts a bunch of filesystems
Copies a slew of "standard" config files to /etc and elsewhere from the NFS mounted archive
Creates a bunch of "stock" users via useradd / groupadd (we also use LDAP.)
Runs Yum to install a whole slew of vendor and local packages
When a server installs itself, we find it's IP by looking in the dhcp leases file on the dhcp server, then ssh into the machine and run another script that changes the hostname, sets the IP to a static address, and uses the HP client tools to reset the ILO Admin password. (ILO is HP's remote console system - we run all our servers headless.) To remove the need for the graphical ILO license, we nuke the GRUB splash image, and add the option to the install / boot to force text mode.
When I setup the kickstart process, I ran it over and over on the same machine until it completed flawlessly - making notes of anything I had to do manually, and then adding back in to the scripts. This can take quite a while, and again is very customized to our particular hardware / network / software set / environment.
The redhat manual on setting up kickstart is actually quite good. http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/sysadmin-guide/
On Wednesday 29 November 2006 14:27, Walt Reed wrote:
When a server installs itself, we find it's IP by looking in the dhcp leases file on the dhcp server, then ssh into the machine and run another script that changes the hostname, sets the IP to a static address, and uses the HP client tools to reset the ILO Admin password. (ILO is HP's remote console system - we run all our servers headless.) To remove the need for the graphical ILO license, we nuke the GRUB splash image, and add the option to the install / boot to force text mode.
I believe that if you kickstart with console options specified with the kernel in the pxelinux.cfg file, anaconda realizes this and sets grub and inittab to use the serial console for output. At least that's what I noticed when kickstarting through PXE a few soekris boxes while back.
Walt Reed wrote:
On Thu, Nov 30, 2006 at 10:49:37AM +1300, MrKiwi said:
Walt Reed wrote:
When building the "replacement" server, it can help to sync / add accounts before all the third-party crap goes on. We do it as part of the kickstart %post scripts. Kickstart from pxe-boot is awesome - especially on HP servers... :-) Once a machine is installed in the rack and powered up for the first time, it's online and usable with all the packages we need, preconfigured, in about 15 minutes.
Walt - Can you show us your scripts?
I am working on something similar - a way to deploy a server using kickstart and then a handwritten script to configure things like postfix, ip, iptables, mysql, apache etc
I imagine however that all you clever people have already got this in your toolbox of tricks,.
Well, obviously they are customized for our situation, and contain a lot of info about our infrastructure that I am not at liberty to divulge, but I can give you some pointers.
Critical to the whole process is setting up DHCP correctly, a tftp server, customizing the files in tftp so that the correct options are set for booting, setting up a local YUM repository, apache to serve the repository and kickstart files, etc. The kickstart script is almost trivial compared to all that. We also use an NFS server for many things.
Kickstart, in %post, runs:
/sbin/chkconfig to enable and disable all the services we need or don't need
Runs ntpdate and hwclock
Creates a bunch or directories in /usr/local and other areas, and mountpoints for various NFS / SAN filesystems
Adds the mount info to fstab
Starts portmapper
Mounts a bunch of filesystems
Copies a slew of "standard" config files to /etc and elsewhere from the NFS mounted archive
Creates a bunch of "stock" users via useradd / groupadd (we also use LDAP.)
Runs Yum to install a whole slew of vendor and local packages
When a server installs itself, we find it's IP by looking in the dhcp leases file on the dhcp server, then ssh into the machine and run another script that changes the hostname, sets the IP to a static address, and uses the HP client tools to reset the ILO Admin password. (ILO is HP's remote console system - we run all our servers headless.) To remove the need for the graphical ILO license, we nuke the GRUB splash image, and add the option to the install / boot to force text mode.
When I setup the kickstart process, I ran it over and over on the same machine until it completed flawlessly - making notes of anything I had to do manually, and then adding back in to the scripts. This can take quite a while, and again is very customized to our particular hardware / network / software set / environment.
The redhat manual on setting up kickstart is actually quite good. http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/sysadmin-guide/
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Thanks Walt,
I like your idea about killing the gui boot part - i should do that too.
For testing my scripts i use vmware, do an install as below, then set a snapshot. I can restore to a snapshot and have the (virtual) machine booted and ready to run the script in about 45 seconds. I find vmware is fantastic for burn-in and development of deployment scripts so long as you aren't testing the hardware specific parts of your script.
For those interested here is what i do;
I also use HP servers (DL380 and DL360) with iLO. I boot from CentOS disk 1, then manually type "linux ks=http://10.1.1.8/installs/HowTo/anaconda-ks.cfg" anaconda-ks.cfg looks like this; ====== # Kickstart file automatically generated by anaconda.
install cdrom lang en_US.UTF-8 langsupport --default=en_NZ.UTF-8 en_NZ.UTF-8 keyboard us xconfig --card "ATI Mach64 3D RAGE II" --videoram 1024 --hsync 31-80 --vsync 56-75 --resolution 800x600 --depth 16 network --device eth0 --bootproto dhcp rootpw --iscrypted blahblahblahblah firewall --enabled --port=22:tcp selinux --disabled authconfig --enableshadow --enablemd5 timezone Pacific/Auckland bootloader --location=mbr # The following is the partition information you requested # Note that any partitions you deleted are not expressed # here so unless you clear all partitions first, this is # not guaranteed to work clearpart --linux --drives=sda,sdb part /boot --fstype ext3 --size=100 --ondisk=sda part pv.9 --size=0 --grow --ondisk=sdb part pv.8 --size=0 --grow --ondisk=sda volgroup VolGroup00 --pesize=32768 pv.9 pv.8 logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=768 --grow --maxsize=1536
%packages grub kernel-smp e2fsprogs lvm2
%post
====== (10.1.1.8 is my utility server with apache and a centos repo) Then i do the same as you - cat /var/lib/dhcp/dhcpd.leases for the IP, then putty in with SSH and paste the following line into the putty shell; cd /tmp;thisfile=install_jslmail.v3.sh;wget -nv -N http://10.1.1.8/installs/HowTo/$thisfile;dos2unix $thisfile;chmod 700 $thisfile;./$thisfile
This grabs my install script and runs it. In the install script i have scripted the following ; 1. hack out the windozy linebreaks in the script (in case i have tweaked it from windoze) into a temp script, then run that script (ie restart yourself after a pass of dos2unix) 2. Set the root password 3. Turn off IP6 4. set the IP address 5. fetch my own repo file for yum (which means packages come from my local repo @ 100mbps) 6. grab and install dags rpmforge rpm 7. echo "includepkgs=clamav clamav-devel clamav-db unrar smbldap-tools perl-Crypt-SmbHash perl-IO-Socket-SSL perl-ldap perl-Unicode-String perl-Unicode-Map8 perl-Unicode-MapUTF8 perl-Convert-BER perl-Jcode perl-Unicode-Map perl-Net-SSLeay">>/etc/yum.repos.d/rpmforge.repo 8. Do a yum -y update (this gets the latest kernel) 9. Reboot At this point we have the new IP address, IP6 turned off and the latest kernel loaded. Reconnect to the IP address specified in the script and re-run to last command (ie Up arrow, Enter - the script will skip steps 1-9) 10. grab the latest iptables config from my server, restart iptables 11. Turn off some services with chkconfig 12. Turn on daily updates for "locate" 13. yum the following packages ; yum-plugin-protectbase, joe, ntp, gcc, glibc-devel, autoconf, automake, kernel-smp-devel, bzip2-devel curl curl-devel rpm-build rpm-devel sendmail-devel zlib-devel 14 run ntpdate to my local timeserver 15 Set the hostname using "hostname $mynewhostname" - maybe this is not optimal 16. Install mysql, set root pwd 17. Install openldap, openldap-clients, config and start 18. Add a bunch of ldap entries for the domain 19. Install php5 using "yum -y --enablerepo=centosplus install php php-gd php-pear php-ldap php-mysql php-mbstring" 20. Install and start apache 21. Install phpldapadmin and config 22. Add a bunch of ldap users 23. Set some aliases and run newalias 24. Install samba, config and start 25. Install postfix, config and start 26. Install amavisd-new, clamd and spamassassin 27. Install phpMyAdmin - not really needed, remove later 28. Install webmin - also not really needed, remove later.
I agree on this it could make things bad especially if you have applications with users account, uid and gid matters and also if there are nfs mount points that applications use and has to be migrated or copy over, be care wary of user and group ownership and permission.
On 11/29/06, Kevan Benson kbenson@a-1networks.com wrote:
On Wednesday 29 November 2006 05:43, Walt Reed wrote:
On Wed, Nov 29, 2006 at 01:31:48PM -0000, Nigel Kendrick said:
I am doing a server swap out tomorrow and wondered if there was a utility that will copy user account details and their current passwords from one server to another (both CentOS 4) - there's only about 15 to do so it's not a major issue.
Rsync and scp are your friend.
You can either cut and paste the user info from the /etc/passwd, shadow, and group files manually, or copy the entire files which wiill also copy over all the system accounts (root password and such):
cd /etc scp -p passwd shadow group newserver:/etc
Then of course you will probably need to copy the user home directories over:
cd /home rsync -aze ssh * newserver:/home
It's worth noting that if you use external packages (rpmforge, kbsingh), that some packages may create users without a set UID (as the core packages seem to have), and if already installed on the new system, it might be using a different UID. In these cases, you should either copy regular user portions of the files only, or take a careful look at a diff between the old and new files to ensure there are no problems.
This caused me a few minutes of confusion with clamav/clamd (specifically the milter socket) which had an incorrect owner after passwd sync on a mail server migration.
--
- Kevan Benson
- A-1 Networks
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Kevan Benson -
Matthew Miller -
MrKiwi -
Nigel Kendrick -
thad -
Walt Reed