Re: Linux Installer Question

Jens Rühmkorf <[email protected]> Mon, 06 Jun 2005 17:39:26 +0200
Newsgroups gmane.org.user-groups.linux.beijing.tech
Message-ID <42A46E2E.8010507__33841.6495513686$1118072329$gmane$org@uni-koeln.de>
Hi Charles, hello Blug-People!

Charles Hall schrieb:
> Hello Blug People, I have a question about the Red Hat installer that
>  I hope you may be able to help answer.
> 
> First some background: I have a linux server that was breached and 
> now many commands result in seg faults and core dumps. I would 
> reinstall but the server is in Los Angeles and I am in Beijing.

That is, you only have remote access, nobody could do a 'hardware reset'
for you?

> I have all of the RPM's for the original RH8 install available on the
> server so I thought maybe I could reinstall the RPM's. The major
> problem is that rpm itself wont run. I am not sure why, the database
> rebuilds properly but the command still core dumps. I think it is a
> linking problem and thought maybe statically linked binaries may be
> of assistance.
> 
> I was thinking that the installer uses RPM's for the install process
>  and was wondering how things like RPM and its dependencies are 
> installed from RPM's when the tools are not yet available.

I don't know what Fedora/Redhat does for sure (I mainly use Debian), but
usually a distribution provides some bootstraping tools to install to a
"new" client. (Debian used to have dbootstrap for that purpose).

After all, rpm can be run off a boot cd and allows the user to install
software to a different directory than / (like /target), so the
bootstraping tool only needs to provide rpms whith all dependencies
resolved.

E.g. the following commands extract PACKAGE.rpm to the current work
directory:

rpm2cpio PACKAGE.rpm | cpio --extract --make-directories -mv

But this only covers the extraction of data, I don't know what about
everything else that's done during installation of a package, like
scripts. When using "rpm" you also have the --relocate and --prefix
options (but they don't work 100% if recall correctly).

So what I would probably do:

1. Retrieve all information from /var, /etc + /boot/config-KVERS;
especially the rpm-db.

2. Get a good chroot-environment to your server in LA, that has all
tools you might need. You can build that in Beijing and:

* Either transfer it as tar file (tar cfvpz) or

* build the chroot inside a file, that you transfer later to LA and
mount it with -o loop:

-- snip --
root@baselitz[/tmp]# dd if=/dev/zero of=./CHROOT bs=1k count=102400
102400+0 records in
102400+0 records out
104857600 bytes transferred in 0.746838 seconds (140402060 bytes/sec)
root@baselitz[/tmp]# mke2fs -F ./CHROOT
mke2fs 1.37 (21-Mar-2005)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
25688 inodes, 102400 blocks
5120 blocks (5.00%) reserved for the super user
First data block=1
13 block groups
8192 blocks per group, 8192 fragments per group
1976 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Writing inode tables: done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
root@baselitz[/tmp]# mount -o loop ./CHROOT /mnt/
root@baselitz[/tmp]# df -h /mnt
Filesystem            Size  Used Avail Use% Mounted on
/tmp/CHROOT            97M   13K   92M   1% /mnt
-- snap --

This gives you a file that has 97Megs space for your chroot. I found a
small howto [1] for mandrake distros that explains building a chroot.
I'm sure others on this list can provide you with more information
regarding rpm+redhat and chroot creation ;)

3. Once you have your chroot up and running, you can "mount --bind" all
broken directories into it:

-- snip (on your machine in LA) --
root@baselitz[/tmp]# mkdir -p /mnt/BROKEN/{root,usr,var,etc}
root@baselitz[/tmp]# mount --bind /root/ /mnt/BROKEN/root/
root@baselitz[/tmp]# mount --bind /usr/ /mnt/BROKEN/usr/
root@baselitz[/tmp]# chroot /mnt/
-- snap --

Then simply work inside your chroot and start fixing ...

Different ideas:

* One solution would consist of setting the server up as desired (in
Beijing, using a tar-file) and transferring the data to LA. Then you
could create a new, fresh partition, untar everything (check that the
/dev-directory is sane, especially when using an old linux) into this
partition and: change the root file-system to this partition on the fly
with the running kernel. For this you might take a look into [2] (very
well written although outdated) and [3]. Some distributions use this
when "booting into" your fresh installed client. Besides mount --bind
you also need the /proc (and /sys) filesystem(s) inside the chroot.

* Use virtualizing techniques to abstract your services from the
underlying hardware. Some techniques even allow you to migrate one
service from one server to another server, if a system is compromised,
broken, etc. Some proprietary tools:
- VMWare
- Virtual Server 2005 (from Microsoft)
and some free alternatives:
- Linux VServer [4]
- Xen [5]

I probably wouldn't use UML for that. I would run for VMWare or the
Linux VServer.

> I was thinking that with an install cd I may be able to get some 
> extra tools that will allow me to install fresh files from RPM's. I 
> looked at the install CD but there are no binaries.

An install CD usually boots a kernel+initrd and mounts everything it
needs as loop-device and/or copies data to a temporary ram disk. Thus
you won't see any binaries on the CD.

The standard for bootable CDs is called 'El Torito'. The concept is that
your BIOS treats the CD you boot from like a floppy initially and
expects to find an image of a bootable flopy ont the CD.

When you mount the CD you won't see this image. Nowadays ISOLINUX [6] is
used for this.

> Any ideas would be really helpful.
> 
> Thank you, -Chuck Hall

I hope this gets you started ;)

Kind regards from Cologne,
Jens

[1] http://qa.mandrakesoft.com/twiki/bin/view/Main/ChrootHowTo
[2] Booting Linux: The History and the Future:
    http://www.almesberger.net/cv/papers.html
[3] "man 8 pivot_root"
[4] http://linux-vserver.org/
[5] http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
[6] http://syslinux.zytor.com/iso.php

-- 
Jens
-------------------------------------------------------------------------
            Jens Rühmkorf
  Institut für Informatik   E-Mail  : [email protected]
      Universität zu Köln
             Pohligstr. 1   Telefon : +49 221 470 5381
             D-50969 Köln   Fax     : +49 221 470 5387
-------------------------------------------------------------------------