[nycbug-talk] rc.conf / rc'ng hacking

[Mark Saad]

On Thu, Oct 13, 2011 at 3:39 PM, Charles Sprickman <spork at bway.net> wrote:
>
> On Oct 13, 2011, at 2:59 PM, Isaac Levy wrote:
>
>> On Oct 13, 2011, at 2:53 PM, Charles Sprickman wrote:
>>
>>>> - The mfsroot bit:
>>>
>>> Just a quick pointer in case you're not aware of it - mfsbsd might be helpful as it's already got many of the basics in doing a remote install/upgrade handled.  http://mfsbsd.vx.sk/  It's based on "depenguinator".  I use it in combination with PXE booting, but that's not the only option.
>>>
>>> Charles
>>
>> Quick question to clarify: this is still a fairly risky procedure, no?  Some partition on the machine has to be stable enough to persist the mfsroot for reboot/install, right?
>
> My use case is totally different, but IIRC you can use this similar to the original depenguinator tool on a running system.  It is risky - there's no turning back once you dd the image to the drive.
>
> I just noticed that it now has a section in the handbook:
>
> http://www.freebsd.org/doc/en/articles/remote-install/preparation.html
>
>> I've never put mfsroot and bare-metal upgrades/installs in the same thought before... so this is both intriguing and scary :)
>
> I'm really happy with mfsbsd here - it's used for two things.  It's available as sort of a "livefs" rescue tool that supports ZFS on root and has all the tools needed if you need to boot a box and roll back to a known good snapshot, and it's also our default installer for new or recycled hardware.  We use PXE to boot it and then use a slightly modified version of mm's zfsinstall script (included in mfsbsd) to do the install.  It's very easy to add additional packages to the mfsbsd image as well if you need any custom tools.  We do have remote console (but not kvm) access and that's needed to toggle between network or hdd booting in the bios.  We keep multiple mfsbsd images around too - both for different FBSD versions and for i386 and amd64.  Toggling between them simply requires an edit in dhcpd.conf on the dhcp server.
>
> Oh, it's also handy for pre-upgrade testing - it's a nice non-destructive way to verify that whatever new version of FreeBSD we're toying with at the very least boots and can go multi-user without wiping anything.  It's currently one of my favorite hammers.
>
> Charles
>
>> Rocket-
>> .ike
>>
>>
>
>
Update on this. Ohh and by the way its BSD related.

So I worked out the details on this crazy remote install I was talking about .

So here are the changes

1. I made a tar ball of the 7.3-RELEASE kernel from the install media.
I have the install iso mounted in /mnt/install/74/
cat /mnt/install/73/kernel/generic.?? > /mnt/work/kernel-7.3-RELEASE-amd64.tgz

2. I made a custom mfsroot with a static IP assignment for the remote
DC I am working on .
I have the following mfsroot attached and mounted in  /mnt/mfs ,
/mnt/work/mfsroot-7.3-RELEASE-amd64-sj2-static.dl360g5
The install.cfg is simple

# Turn on extra debugging.
debug=YES
country=232
nonInteractive=YES
noConfirm=YES
noWarn=YES
tryDHCP=NO
netDev=bce0
ipaddr=10.9.8.249
netmask=255.255.255.0
defaultrouter=10.9.8.1


# My host specific data
domainname=longcount.org
# DHCP does this for us - if yours doesn't, specify hostname
hostname=reimage-sj

# Which installation device to use
nfs=10.9.8.130:/ifs/data/install/fbsd73amd/
mediaSetNFS
#mediaSetFTP

disk=da0
partition=all
bootManager=boot
diskPartitionEditor
#############################################################
# - All sizes are expressed in 512 byte blocks!
# - "Size in MB" = sectors * 512 / 1024 / 1024
# - "Number of blocks" = xsize in mb * 1024 * 1024 / 512
# The non-zero value after the mountpoint means enable soft updates
# All sizes are expressed in 512 byte blocks!
#
#4GB /var, 2GB swap and the rest in /

da0s1-1=ufs 8388608 /var 1
da0s1-2=swap 4194304 none
da0s1-3=ufs 0 /

# Let's do it!
diskLabelEditor
nstallCommit

package=bash-4.0.35
packageAdd
package=vim-lite-7.2.344
packageAdd
package=rsync-3.0.7
packageAdd
package=perl-5.10.1
packageAdd
package=python26-2.6.4
packageAdd
package=sudo-1.7.2.5
packageAdd
package=portaudit-0.5.14
packageAdd
package=curl-7.19.7_1
packageAdd
package=openldap-client-2.4.21
packageAdd
package=portupgrade-2.4.6_3,2
packageAdd
package=compat6x-amd64-6.4.604000.200810_3
packageAdd
package=pciids-20091229
packageAdd
package=unzip-6.0
packageAdd
package=syslog-ng-1.6.12_1
packageAdd
package=cciss_vol_status-1.06
packageAdd
package=dmidecode-2.10
packageAdd
package=longcount-custom-2.0
packageAdd
shutdown

3. I scp the kernel and mfsroot to the box I want to reinstall, and
drop in a new loader.conf and loader.rc

loader.conf
mfsroot_load="YES"
mfsroot_type="mfs_root"
mfsroot_name="/boot/mfsroot-7.3-RELEASE-amd64-sj2-static.dl360g5"

loader.rc
load /boot/GENERIC/kernel
load -t mfs_root /boot/mfsroot-7.3-RELEASE-amd64-sj2-static.dl360g5
set vfs.root.mountfrom="ufs:/dev/md0c"
boot

Note i untared my kernel-7.3-RELEASE-amd64.tgz into /boot

Ok so lastly when i reboot this box i get the server re-installed in
the way i want, no pxe-boot needed.
All in all this allows us to remotely re-image older 6.x servers into
7.x servers with out changing any remote network settings and to
return the server to a working state after the upgrade.

This method worked on 15 servers so far more to come.

-- 

Mark Saad | mark.saad at ymail.com