Differences between revisions 7 and 8
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
<<TableOfContents>>

= Bootstrap =
Line 59: Line 63:
== PAM == = PAM =
Line 67: Line 71:
=== /etc/pam.d/common-account: === == /etc/pam.d/common-account: ==
Line 77: Line 81:
=== /etc/pam.d/ssh: === == /etc/pam.d/ssh: ==
Line 88: Line 92:
=== Discussion === == Discussion ==
Line 99: Line 103:

= OpenAFS =

Building the kernel module is a bit weird, since Debian has changed they way they handle kernel versions (I could reasonably claim it is the module packaging being broken; but I bet nobody else builds module packages this way anymore).


{{{
cd /usr/src
rm -rf ./modules
tar -jxvf openafs.tar.bz2
}}}

The modules need to be built such that the package name and "Recommend:" field reflect the correct Debian kernel package (e.g, linux-image-''3.2.0-4-amd64''). But you want the actually package version to reflect the debian revision of the kernel (e.g., ''3.2.41-2''). This is necessary for the modules themselves to get installed to the right place (/lib/modules/''3.2.0-4-amd64''), and so that the sources that built the modules are properly traceable as well.

To do this, set KVERS to the "package name version" and KDREV to the "debian revision."

E.g.,
{{{
cd /usr/src/modules/openafs
make -f debian/rules KSRC=/usr/src/linux-headers-3.2.0-4-amd64 KVERS=3.2.0-4-amd64 KDREV=3.2.41-2 binary
}}}

Bootstrap

On the hosting machine

debootstrap wheezy /path/to/root http://debian.osuosl.org/debian/
mount --bind /dev /path/to/root/dev
mount -t proc proc /path/to/root/proc
mount -t sysfs sysfs /path/to/root/sys
chroot /path/to/root /bin/bash

In the wheezy chroot

cat > /etc/apt/sources.list << EOF
deb http://debian.osuosl.org/debian/ wheezy main non-free contrib
deb http://security.debian.org/ wheezy/updates main non-free contrib
EOF
aptitude update

dpkg-divert --local --rename --divert /sbin/start-stop-daemon.real --add /sbin/start-stop-daemon
#!/bin/sh
cat > /sbin/start-stop-daemon << EOF
echo invoked fake start-stop-daemon... > /dev/stderr
exit 0
EOF
chmod a+x /sbin/start-stop-daemon

# XXX: should probably set APT::Install-Recommends false here.

aptitude dist-upgrade
aptitude install `tasksel --task-packages standard`
dpkg-reconfigure locales

dpkg-reconfigure tzdata

aptitude install linux-image-3.2.0-4-amd64
# pulls in:
#     busybox{a} firmware-linux-free{a} initramfs-tools{a} klibc-utils{a} 
#     libklibc{a} libuuid-perl{a} linux-base{a} linux-image-3.2.0-4-amd64 
aptitude install openssh-server

# Fix /etc/hostname and /etc/hosts
# Setup /etc/network/interfaces
# Check /etc/resolv.conf

cat > /etc/fstab << EOF
/dev/xvda1      /               ext4    rw,noatime,errors=remount-ro 0       1
/dev/xvda2      swap            swap    sw              0       0
EOF

# Add "H0:2345:respawn:/sbin/getty 38400 hvc0" to /etc/inittab.

rm /sbin/start-stop-daemon
dpkg-divert --rename --remove /sbin/start-stop-daemon

passwd root

PAM

It looks like we only need a few minor tweaks to make the Debian settings work.

sed -i 's/\(pam_krb5.so.*minimum_uid\)=1000/\)=110/' /etc/pam.d/*

/etc/pam.d/common-account:

Add:

account sufficient                      pam_krb5.so minimum_uid=110

before

# here are the per-package modules (the "Primary" block)

/etc/pam.d/ssh:

Replace:

# Standard Un*x authorization.
@include common-account

with

account    required     pam_unix.so broken_shadow

Discussion

  • pam_krb5.so—"account" only works after "auth"

    • caused an issue with sshd if user is marked as shadowed in /etc/passwd (password field is "x")
      • ssh runs "account" before "auth", so pam_krb5.so would return PAM_IGNORE; pam_unix.so would fail due to missing shadow entry
      • solution is to use the broken_shadow arg on pm_unix.so for ssh only
    • will never succeed without an "auth" phase
      • this also means having it as "sufficient" for atd/cron does not allow users without shadow entries to run atd/cron jobs (assuming "x" in /etc/passwd)
  • pam_afs_session.so
    • will silently succeed if AFS is not running
    • so, it's not necessary to explicitly disable it for non-AFS machines

OpenAFS

Building the kernel module is a bit weird, since Debian has changed they way they handle kernel versions (I could reasonably claim it is the module packaging being broken; but I bet nobody else builds module packages this way anymore).

cd /usr/src
rm -rf ./modules
tar -jxvf openafs.tar.bz2

The modules need to be built such that the package name and "Recommend:" field reflect the correct Debian kernel package (e.g, linux-image-3.2.0-4-amd64). But you want the actually package version to reflect the debian revision of the kernel (e.g., 3.2.41-2). This is necessary for the modules themselves to get installed to the right place (/lib/modules/3.2.0-4-amd64), and so that the sources that built the modules are properly traceable as well.

To do this, set KVERS to the "package name version" and KDREV to the "debian revision."

E.g.,

cd /usr/src/modules/openafs
make -f debian/rules KSRC=/usr/src/linux-headers-3.2.0-4-amd64 KVERS=3.2.0-4-amd64 KDREV=3.2.41-2 binary

kbare at CLUB.CC.CMU.EDU/Wheezy (last edited 2019-07-20 22:35:40 by kbare@CLUB.CC.CMU.EDU)