User talk:Jch: Difference between revisions
| Line 187: | Line 187: | ||
Everything else should be fully automatic according to some config file (stating the http-proxy, the time server, the log server, ...). | Everything else should be fully automatic according to some config file (stating the http-proxy, the time server, the log server, ...). | ||
The I will just run the script, watch my dhcp logs to discover the new IP assigned, then log in with ssh without password to customize it further but at high level only (will be a robot and not me in fact). | The I will just run the script, watch my dhcp logs to discover the new IP assigned (that's why the name is a parameter), then log in with ssh without password to customize it further but at high level only (will be a robot and not me in fact). | ||
I guess it would be something like emulate boot from usb key with specific overlay already on key... <br/> | I guess it would be something like emulate boot from usb key with specific overlay already on key... <br/> | ||
Revision as of 17:58, 24 January 2015
NFS bug study
All debian used are fresh install of wheezy 7.8.
All alpine used are fresh install of edge. (will also try vanilla kernel in KVM)
All boxes are supermicro servers with bi-Xeon running AL from USB key.
I do not have physical access to the boxes!
The NFS-servers are configured to export
/srv/home 192.168.1.0/24(rw,sync,no_subtree_check)
The nfs-clients are configured to mount from fstab
storage:/srv/home /home nfs noauto,defaults,noexec 0 0
"storage" is defined in /etc/hosts to point to the right server.
The test is done with
mount /home
We will compare the dmesg outputs, the ls -ld /home outputs, the cat /home/test and touch /home/toto ones. /home/test is prepared on the server (just a text file containing "do you see me?"). Those tests are run as root user.
NFS-server in KVM-Debian
fresh install with tasksel "file server"
this KVM in running on bare metal alpine
nfs-client in KVM AL
mount /home gives
in dmesg
[73460.112383] RPC: Registered named UNIX socket transport module. [73460.112386] RPC: Registered udp transport module. [73460.112388] RPC: Registered tcp transport module. [73460.112389] RPC: Registered tcp NFSv4.1 backchannel transport module. [73460.165060] svc: failed to register lockdv1 RPC service (errno 111). [73460.165069] lockd_up: makesock failed, error=-111 [73460.217513] NFS: Registering the id_resolver key type [73460.217524] Key type id_resolver registered [73460.217525] Key type id_legacy registered
in ls -ld /home/
drwxr-xr-x 2 42949672 42949672 6 Jan 23 12:27 /home
in cat /home/test
Do you see me?
in touch /home/toto
touch: /home/toto: Permission denied
nfs-client in KVM debian
dmesg is empty
ls -ld /home
drwxr-xr-x 2 root root 17 Jan 23 08:39 /home
cat /home/test
Do you see me?
touch /home/toto (even after adding rw to the mount options in fstab)
touch: cannot touch `/home/toto': Permission denied
Some pointers to investigate this permission problem:
To begin using machine as an NFS client, you will need the portmapper running on that machine, and to use NFS file locking, you will also need rpc.statd and rpc.lockd running on both the client and the server.
'
nfs-client in LXC AL (on bare metal AL)
apk add nfs-utils
dmesg empy sofar
mount /home
dmesg
[4153944.457610] RPC: Registered named UNIX socket transport module. [4153944.457615] RPC: Registered udp transport module. [4153944.457618] RPC: Registered tcp transport module. [4153944.457620] RPC: Registered tcp NFSv4.1 backchannel transport module. [4153944.504475] svc: failed to register lockdv1 RPC service (errno 111). [4153944.504484] lockd_up: makesock failed, error=-111 [4153944.681725] NFS: Registering the id_resolver key type [4153944.681744] Key type id_resolver registered [4153944.681748] Key type id_legacy registered
ls -ld /home
drwxr-xr-x 2 42949672 42949672 17 Jan 23 14:39 /home
cat /home/test
Do you see me?
touch /home/toto
touch: /home/toto: Permission denied
nfs-client in LXC AL (in KVM AL)
apk add nfs-utils
but
# mount /home mount.nfs: rpc.statd is not running but is required for remote locking. mount.nfs: Either use '-o nolock' to keep locks local, or start statd. mount.nfs: an incorrect mount option was specified mount: permission denied (are you root?)
and
# /etc/init.d/rpc.statd start * Caching service dependencies ... [ ok ] * Starting rpcbind ... [ ok ] * Starting NFS statd ... * start-stop-daemon: failed to start `/usr/sbin/rpc.statd' [ !! ] * ERROR: rpc.statd failed to start
dmesg
[74747.135827] rpcbind[6718]: segfault at 7ccfe7b0 ip 000072977ccef5cd sp 00007c6b3e329a68 error 4 in ld-musl-x86_64.so.1[72977cca0000+85000] [74747.135841] grsec: Segmentation fault occurred at 000000007ccfe7b0 in /sbin/rpcbind[rpcbind:6718] uid/euid:100/100 gid/egid:101/101, parent /bin/busybox[init:1831] uid/euid:0/0 gid/egid:0/0 [74747.135887] grsec: bruteforce prevention initiated due to crash of /sbin/rpcbind against uid 100, banning suid/sgid execs for 15 minutes. Please investigate the crash report for /sbin/rpcbind[rpcbind:6718] uid/euid:100/100 gid/egid:101/101, parent /bin/busybox[init:1831] uid/euid:0/0 gid/egid:0/0
nfs-client in LXC debian (in KVM AL)
apt-get install nfs-commonn
gives
[FAIL] Starting NFS common utilities: statd idmapd failed!
then mount /home gives same results in guest as in host
NFS-server in KVM-Alpine
Done from a KVM running in memory straight from the iso
CDROM="/my/path/alpine-mini-3.1.1-x86_64.iso"
qemu-system-x86_64 -name test -enable-kvm -cpu qemu64 -m 256 -smp 1 -curses \
-net nic,vlan=0,model=virtio,macaddr=52:54:32:a0:a0:a0 \
-net tap,vlan=0,script=/etc/openvswitch/ovs-ifup-lan,downscript=/etc/openvswitch/ovs-ifdown-lan,ifname=test0 \
-cdrom ${CDROM}
do not forget to issue "grsec nomedeset" at SYSLINUX prompt or you loose the output (I'm doing it trough ssh term)
# setup-alpine # no disk install at all, no apk cache but proxy # . /etc/profile.d/proxy.sh # apk add nfs-utils # echo "/home 192.168.1.0/24(rw,no_root_squash)" >> /etc/exports # echo "Do you see me?" > /home/test # /etc/init.d/nfs start * Caching service dependencies ... [ ok ] * Starting rpcbind ... [ ok ] * Starting NFS statd ... * start-stop-daemon: failed to start `/usr/sbin/rpc.statd' [ !! ] * ERROR: rpc.statd failed to start * ERROR: cannot start nfs as rpc.statd would not start # dmesg # only relevant lines displayed [ 462.262020] rpcbind[1890]: segfault at 1e783940 ip 000070591e773f1d sp 00007dc1da01a4d8 error 4 in ld-musl-x86_64.so.1[70591e724000+86000] [ 462.262032] grsec: Segmentation fault occurred at 000000001e783940 in /sbin/rpcbind[rpcbind:1890] uid/euid:100/100 gid/egid:101/101, parent /bin/busybox[init:1] uid/euid:0/0 gid/egid:0/0 [ 462.262043] grsec: bruteforce prevention initiated due to crash of /sbin/rpcbind against uid 100, banning suid/sgid execs for 15 minutes. Please investigate the crash report for /sbin/rpcbind[rpcbind:1890] uid/euid:100/100 gid/egid:101/101, parent /bin/busybox[init:1] uid/euid:0/0 gid/egid:0/0 # poweroff
Let's try with the vanilla kernel
CDROM="/my/path/alpine-vanilla-3.1.1-x86_64.iso"
with same command line and same sequence of instructions
test:~# /etc/init.d/nfs start * Caching service dependencies ... [ ok ] * Starting rpcbind ... [ ok ] * Starting NFS statd ... * start-stop-daemon: failed to start `/usr/sbin/rpc.statd' [ !! ] * ERROR: rpc.statd failed to start * ERROR: cannot start nfs as rpc.statd would not start test:~# dmesg [ 243.445710] rpcbind[1930]: segfault at 33f30940 ip 00007f5a33f20f1d sp 00007fffa4290e48 error 4 in ld-musl-x86_64.so.1[7f5a33ed1000+86000] test:~# poweroff
Obviously I will not be able to test clients now...
nfs-client on bare metal AL
nfs-client in KVM AL
nfs-client in KVM debian
nfs-client in LXC AL (on bare metal AL)
nfs-client in LXC AL (in KVM AL)
nfs-client in LXC debian (in KVM AL)
How to automate KVM creation
The goal is not only to have a working install but to have it at the after setup-alpine stage without human intervention... Tis is the first stages of a work in progress...
I want to pass a Block Device and a name as parameters. The block device could be an image file, a LV, a NBD, a hdd, a raid array, whatever.
Everything else should be fully automatic according to some config file (stating the http-proxy, the time server, the log server, ...).
The I will just run the script, watch my dhcp logs to discover the new IP assigned (that's why the name is a parameter), then log in with ssh without password to customize it further but at high level only (will be a robot and not me in fact).
I guess it would be something like emulate boot from usb key with specific overlay already on key...
then run setup-disk with proper parameters on the command line to avoid the interactive process (like setup-alpine does)...
Methink this could be done from a couple of scripts put in /etc/local.d/. The last.stop one deleting all of them to be clean at next reboot.
Let's start easy ;)
How to prepare a img file to emulate an USB key
first a working example done in console (accessed trough ssh).
Will build a script from it...
lvcreate -n bench-ext2 -L 5G systems apk add multipath-tools syslinux dosfstools kpartx -as /dev/mapper/systems-bench--ext2 mkdosfs -F32 /dev/mapper/systems-bench--ext2p1 dd if=/usr/share/syslinux/mbr.bin of=/dev/mapper/systems-bench--ext2 syslinux /dev/mapper/systems-bench--ext2p1 mkdir -p /media/bench-ext2 mount -t vfat /dev/mapper/systems-bench--ext2p1 /media/bench-ext2 mount /isos/alpine-mini-3.1.1-x86_64.iso /media/cdrom cd /media/cdrom cp -a .alpine-release * /media/bench-ext2/ rm /media/bench-ext2/*.apkovl.tar.gz cd umount /media/bench-ext2 umount /media/cdrom screen -d -m -S KVM-bench-ext2 qemu-system-x86_64 -name bench-ext2 -enable-kvm -cpu qemu64 -m 2048 -smp 4 -curses -net nic,vlan=0,model=virtio,macaddr=52:54:32:b1:c2:d3 -net tap,vlan=0,script=/etc/openvswitch/ovs-ifup-lan,downscript=/etc/openvswitch/ovs-ifdown-lan,ifname=ext2 -usbdevice file:/dev/mapper/systems-bench--ext2 screen -r KVM-bench-ext2