PXE boot nameserver on client

New features which should be implemented in Porteus; suggestions are welcome. All questions or problems with testing releases (alpha, beta, or rc) should go in their relevant thread here, rather than the Bug Reports section.
Post Reply
steveumbal
Ronin
Ronin
Posts: 2
Joined: 04 Jun 2014, 22:54
Distribution: Porteus
Location: Italy

PXE boot nameserver on client

Post#1 by steveumbal » 05 Jun 2014, 08:56

First, thanks for all your improvement to this remarkable distro ...

Managing to boot from a pxe environment (dhcp, tftp, nfs, http) that I use to serve other distributions, I found something weird:
nameserver ip on the client never follow dhcp directive (tried also with "option domain-name-servers") and seems fixed to the tftp or nfs server (same server in my case).

Following previous topic, in pxelinux.cfg/default i deleted 'IPAPPEND 1', added ip=SERVER:192.168.249.9 (my nfs server) and purged everything else:
-----------------------------------------
PROMPT 0
DEFAULT Linux

LABEL Linux
MENU LABEL Graphics mode
KERNEL /vmlinuz
APPEND initrd=/initrd.xz ip=SERVER:192.168.249.9
------------------------------------------

PXE booting works correctly but nameserver is wrong.

Well, udhcpc ten seconds discover delay is little annoying but found it also in other distro ... and I was obliged to place a symlink from nfs server "/srv/pxe/porteus" to "/tftboot/porteus31/porteus" where phisically reside my modules - and exported too - ... not a problem for a single porteus but make impossible (i think) to serve different flavour of the distro.

User avatar
pumbaa2
White ninja
White ninja
Posts: 29
Joined: 08 May 2012, 10:39
Distribution: Slackware 13.37
Location: Melbourne, FL
Contact:

Re: PXE boot nameserver on client

Post#2 by pumbaa2 » 05 Jun 2014, 09:57

I'm not sure I follow. I am running DHCPD in Slackware 13.37 with TFTP to host my PXE Boot Environment. My machine is also the firewall/router for the network. I booted into PXE Porteus 3 and looked in /etc/resolv.conf and it seems to have the correct DNS Server. But my machine runs DNS as well so the IP points to the router machine as I also run named.

/etc/dhcpd.conf is as follows:

Code: Select all

# dhcpd.conf
#
# RayLine Networks DHCP Server
subnet 10.69.0.0 netmask 255.255.0.0 {
        option routers 10.69.1.1;
        option domain-name "rayline.net";
        option domain-name-servers 10.69.1.1;
        option netbios-name-servers 10.69.1.1;
        option time-offset -18000;
        option ntp-servers 10.69.1.1;
        authoritative;
        next-server 10.69.1.1;
        filename "/pxelinux.0";
        range 10.69.1.200 10.69.1.254;
}
option routers sets the default gateway on clients.
option domain-name-servers sets the DNS Server on Clients.
option netbios-name-servers sets the address to your WINS Server (used by Windows)
next-server tells the network boot process where to TFTP the bootloader file from
filename tells the network boot process the file to TFTP (bootloader file pxelinux.0 for syslinux loader, startrom.0 for Windows PE over network). However, I always start with pxelinux.0 as I can call startrom.0 from pxelinux.0 if I need Windows PE Environment.

The only problem I've had is that Porteus doesn't pass option domain-name, so I resolve local clients I must specify .rayline.net which gets annoying.

User avatar
fanthom
Site Admin
Site Admin
Posts: 4588
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
Contact:

Re: PXE boot nameserver on client

Post#3 by fanthom » 05 Jun 2014, 11:29

i can confirm this, in linuxrc there is following code:

Code: Select all

if [ "$IP" -a -x /union/etc/rc.d/rc.networkmanager ]; then
    if [ -z "`egrep -o " copy2ram( |\$)" /proc/cmdline`" -o -d /mnt/nfs/storage/client-$MAC ]; then
        echo "nameserver $IP" > /union/etc/resolv.conf
        nmc=/union/etc/NetworkManager/NetworkManager.conf; HW=`ifconfig | grep eth0 | cut -dW -f2 | cut -d" " -f2`
        ! grep -q "unmanaged-devices=mac:$HW" $nmc && sed -i '/\[keyfile\]/ a\unmanaged-devices=mac:'$HW'' $nmc
    fi
fi
the only problem is that i dont remember why i'm forcing nameserver to match the $IP variable :pardon:

i know for sure that if:
- we are doing PXE boot ($IP parameter)
- and 002-xorg.xzm is loaded (-x /union/etc/rc.d/rc.networkmanager)
- and 'copy2ram' is skipped (-z "`egrep -o " copy2ram( |\$)" /proc/cmdline`)
- or copy2ram is present but we are saving changes on the NFS server (-d /mnt/nfs/storage/client-$MAC)
then we cant let network manager to overtake the connection: (! grep -q "unmanaged-devices=mac:$HW" $nmc && sed -i '/\[keyfile\]/ a\unmanaged-devices=mac:'$HW'' $nmc)

reason:
if NM overtake the connection then existing link to the NFS server is lost so reading from modules or saving changes over the network is not possible. Porteus simply dies as soon as NM is active and before going to the GUI. this is clear so far but why did i force the nameserver?

could you remaster initrd, hash out the nameserver line and check if that makes any negative impact?

thanks
Please add [Solved] to your thread title if the solution was found.

User avatar
pumbaa2
White ninja
White ninja
Posts: 29
Joined: 08 May 2012, 10:39
Distribution: Slackware 13.37
Location: Melbourne, FL
Contact:

Re: PXE boot nameserver on client

Post#4 by pumbaa2 » 05 Jun 2014, 11:48

and I was obliged to place a symlink from nfs server "/srv/pxe/porteus" to "/tftboot/porteus31/porteus" where phisically reside my modules - and exported too - ... not a problem for a single porteus but make impossible (i think) to serve different flavour of the distro.
Yeah, the exports are hard coded at this point. That export (/srv/pxe/porteus) and /srv/pxe/storage for the changes. That was my suggestion by saying to make a cheatcode for nfschanges. That way if nfschanges = 192.168.0.1:/porteus/changes would make NFS mount that path and use it for changes. I forgot about the nfssource directory that gets mounted RO to actually get access to the modules.

In order to make a modification currently to Porteus you must modify linuxrc in /mnt/live which is actually in the inird.img file.

This code controls location of the modules on the NFS Server, modify path after $IP but leave destination mountpoint alone:

Code: Select all

    mkdir -p /mnt/nfs/porteus /mnt/nfs/storage; udhcpc; modprobe nfsv4; mount -t nfs4 $IP:/srv/pxe/porteus /mnt/nfs/porteus -o ro,nolock 2>/dev/null || { modprobe nfsv3; mount -t nfs $IP:/srv/pxe/porteus /mnt/nfs/porteus -o ro,nolock 2>/dev/null; }
This code controls location of changes, modify path after $IP: (All instances) but leave destination path alone. You don't have to change the "if" statement but keep in mind that if you don't, the changes location still has to say /srv/pxe/storage in /pxelinux.cfg/default even though you modified the script to use a different mount point (It will still use the new mount point)...

Code: Select all

    MAC=`ifconfig | grep eth0 | cut -d: -f5-7 | sed s/://g | cut -d" " -f1`
    if [ "$CHANGES" = /srv/pxe/storage ]; then
        if lsmod | grep -q nfsv3; then
            mount -t nfs $IP:/srv/pxe/storage /mnt/nfs/storage -o rw,nolock 2>/dev/null && { mkdir -p /mnt/nfs/storage/client-$MAC/changes/home; CHANGES="/storage/client-$MAC"; }
        else
            mount -t nfs4 $IP:/srv/pxe/storage /mnt/nfs/storage -o rw,nolock 2>/dev/null && { mkdir -p /mnt/nfs/storage/client-$MAC/changes/home; CHANGES="/storage/client-$MAC"; }
        fi
    fi
This will allow you to have multiple Porteus installations on 1 PXE/NFS Server. In the future hopefully Porteus will have cheatcodes for nfschanges and nfssource paths that will eliminate this kind of confusion in the future. I don't think the PXE Boot Configuration was thought up enough to allow someone to use anything else but the Porteus PXE Boot Server option. The problem is that the nature of that option will more than likely break someone's network configuration as the DHCP Server will interfere with their router and Porteus PXE Boot is not configured enough to NAT using iptables without manual intervention (Porteus as Router). They should gang up with OpenWRT to make a module to allow boot of Porteus over network from their router. Maybe even commit changes to a USB Drive connected to their router. Now that would be thinking outside the box...

User avatar
fanthom
Site Admin
Site Admin
Posts: 4588
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
Contact:

Re: PXE boot nameserver on client

Post#5 by fanthom » 05 Jun 2014, 12:41

In the future hopefully Porteus will have cheatcodes for nfschanges and nfssource paths that will eliminate this kind of confusion in the future.
i'm against new cheatcodes as we have too many of them already. our goal is to make users life simpler and so far in the whole porteus pxe boot history only two people would benefit from it.
overall - small chance this will happen.

I don't think the PXE Boot Configuration was thought up enough to allow someone to use anything else but the Porteus PXE Boot Server option.
this is true. i can't think why Porteus user would need a 3dr party OS to boot Porteus over PXE while our OS offers this functionality ootb.

The problem is that the nature of that option will more than likely break someone's network configuration as the DHCP Server will interfere with their router and Porteus PXE Boot is not configured enough to NAT using iptables without manual intervention (Porteus as Router).
yes - that's why all the traffic should go through Porteus working as PXE server then to the router.

Code: Select all

client a--------
                         \
client b---------          Porteus PXE server ------- Router ----- Internet
                         /
client c --------
making this configuration automatic would require additional cheatcodes (like router=IP) so i think it's better to leave the configuration for the admin.
Please add [Solved] to your thread title if the solution was found.

steveumbal
Ronin
Ronin
Posts: 2
Joined: 04 Jun 2014, 22:54
Distribution: Porteus
Location: Italy

Re: PXE boot nameserver on client

Post#6 by steveumbal » 07 Jun 2014, 12:17

@ phantom
> could you remaster initrd, hash out the nameserver line and check if that makes any negative impact?
Hashing nameserver line in linuxrc works, now pxe client follows dhcp directive whitout problems

@ pumbaa2
modifications to the path point in linuxrc works too, no need of "/srv/pxe/porteus" symlink anymore, now it's possible to host multiple porteus distro (... remastering each one).

Anyway, live distributions are very powerfull in public sector as kiosks, info boards, shared workstations (with captive
portal autentication). I use some of them in campus (slax, geexbox, tinycore, ...) and no one is forcing me to use a
predefined medium. Perhaps you have to be more proud of your remarcable work thinking that it can be used in scenarios
different from home play.
In the next days I'll go to deploy kiosk version in pxe. Can't deny, that really amazing kiosk distro impressed me and make
me decide to definitely switch from slax (Thomas -1).

Have a nice day

User avatar
pumbaa2
White ninja
White ninja
Posts: 29
Joined: 08 May 2012, 10:39
Distribution: Slackware 13.37
Location: Melbourne, FL
Contact:

Re: PXE boot nameserver on client

Post#7 by pumbaa2 » 11 Jun 2014, 05:02

> yes - that's why all the traffic should go through Porteus working as PXE server then to the router.

Interesting Idea. There is only 2 ways to solve this issue using your current layout:

#1> DHCP From Router and then NAT the connection again out the second ethernet port. This would cause a double NAT condition though. Dealing with Port Forwarding using one router is a pain, having to forward the port twice (once on the router and again on Porteus) would be frustrating.

If your going to use this option, you might as well eliminate the router completely and let Porteus take over those responsibilities. Everything a router can do, Porteus can do and more.

#2> Bridge the two interfaces (1 to the router and the other to the network), or 1 interface (Porteus connected to the router as a client). Disable DHCP Server on the router and configure DHCP Server on Porteus with the default gateway pointed at the router.

This is honestly the way I would go if I wasn't using Slackware 13.1 as the host router. But maybe the OpenWRT idea isn't so bad. The "firmware" is designed to be stored on as little as 4 Meg of Flash Memory, so you know the release is already small. It maybe a good idea to strip down OpenWRT to run in Porteus and only activate it when Porteus is run in PXE Server Mode. This still gives the server a GUI as a workstation, PXE Boot Framework for clients and a nice web interface to interact with the firewall and network configuration. This also opens the doors for easy configuration of WIFI Cards in host mode as that is no doubt the point of OpenWRT. "Reset to factory condition" is simply wipe out changes directory and reboot. Indirectly, Porteus could be one of the safest firewall/routers out there.

This could also open the doors the other way too. People running OpenWRT on their routers could have a Porteus module that once installed allows network boot from their router. The boot files would have to be stored on a Flash Drive, etc and plugged into the router but the router will need that anyway to save changes between clients. The Porteus module's configuration can handle downloading the lastest snapshot of Porteus onto the flash drive, formatting, etc. No doubt a real router doesn't have enough space to handle this on its own without some type of "Mass Storage Device."

User avatar
fanthom
Site Admin
Site Admin
Posts: 4588
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
Contact:

Re: PXE boot nameserver on client

Post#8 by fanthom » 11 Jun 2014, 06:01

you might as well eliminate the router completely and let Porteus take over those responsibilities. Everything a router can do, Porteus can do and more.
unless your PC has only Ethernet card and your internet is coming through the ADSL/VDSL :wink:
Please add [Solved] to your thread title if the solution was found.

Post Reply