Difference between pages "DVDless install" and "X11 over the network"

From Wikislax
(Difference between pages)
Jump to: navigation, search
(Slackware setup)
 
(Kdm)
 
Line 1: Line 1:
 
{{RightTOC}}
 
{{RightTOC}}
  
The (local) network is an additional choice to install Slackware from when your hardware has this capability. Installing from the local network is much faster than from a DVD and is a good choice when playing around with the installation. This page explains how to configure a Slackware server for this usage. It was inspired by the [http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:pxe AlienBob's blog page] on the same topic. To install Slackware over the network we need :
+
Using X over the network affords accessing remote servers graphically as if you were on the console. So for instance, from your Windows workstation, you can run Windows and Linux side by side, full screen, and switch with function-key combinations such as alt-tab or ctrl-alt-F7 or F8. A very handy feature. X is natively present and fast on Linux. On Windows, it will always be a bit slower, and you need to install an X server. [https://sourceforge.net/projects/vcxsrv/ VcXrv] is a very competent one.
  
* A service to download the Slackware files during the Slackware setup. HTTP, FTP, or NFS can be used. In the example below we show how to use the NFS and FTP services included with Slackware.
+
The software presenting an X window on a terminal is called an X server, which is contrary to what we are used to, as the X server is not on the server but actually on the client ! Over the Internet, you will always encapsulate X11 in SSH ('''X11 forwarding''', to configure in '''/etc/ssh/sshd_config''') as the X protocols are not secure. However, X needs a significant bandwidth so it is not likely that you will use it over an ADSL connection as it would be too slow. Optical fiber could be OK though.
* A service implementing the TFTP protocol. TFTP is used to effectively download the bootstrap code from the server identified. We will use the TFTP protocol included with Slackware.
 
  
* A service implementing the BOOTP protocol. BOOTP is used by the PXE firmware to identify on the network a server to download the bootloader code from. The DHCP server included with the Slackware distribution has this capability.
+
For more information on using remote X applications, check this [http://www.xs4all.nl/~zweije/xauth.html mini-HOWTO] or this excellent [http://shop.oreilly.com/product/9780596101954.do O'Reilly book].
  
== Configuring NFS ==
+
== Xdm, Kdm, Gdm ==
  
NFS is SUN's Network File System. It is lightning fast and can be used as a mount point, but depending on configuration may be unsecure and must be used locally only. Also, it uses some random port numbers that need to be fixed if firewalling. The directories used are defined in '''/etc/exports'''. Edit as follows. '''ro''' means read-only, '''sync''' makes sure that no asynchronous requests are made, '''insecure''' affords using different NFS ports from other NFS implementations, '''all_squash''' maps all uids and gids to the anonymous user for public access, '''no_subtree_check''' improves reliability in some circumstances. See '''man exports''' for more details.
+
X requires a daemon on the server to handle connections. The base daemon is Xdm, that offers a graphical login directly under X, with no desktop manager. Access can be local on the computer console, or can be from an X terminal or X emulated terminal on the network.
  
# See exports(5) for a description.
+
The KDE and Gnome desktop environments Kdm and Gdm come with Xdm variants that have a different look and feel. It is possible to run one or several of the three, provided that they will not compete for management of the same terminals.
# This file contains a list of all directories exported to other computers.
 
# It is used by rpc.nfsd and rpc.mountd.
 
 
/var/pub      192.168.53.1/24(ro,sync,insecure,all_squash,no_subtree_check)
 
  
The NFS server is launched using '''/etc/rc.d/rc.nfsd'''. Make this script executable so as to use it on every boot. You can also '''start''' it to test it immediately. The NFS client is launched using '''/etc/rc.d/rc.rpc''' and affords using NFS mount points from other NFS servers. Make this script executable if you want to use it and have it started on every reboot. This can be handy to cross-test NFS machines. Otherwise it should not be necessary.
+
However it makes sense to use only one. Kdm is a good choice as it affords choosing the Session Window Manager (Kde, Xfce4, ...) from the connection dialog box.
  
# chmod u+x /etc/rc.d/rc.nfsd
+
== Kdm ==
# chmod u+x /etc/rc.d/rc.rpc
 
  
== Configuring FTP ==
+
For KDE to manage X terminals over the network, update '''/etc/kde/kdm/kdmrc''' specifying '''Enable=true''' for '''[Xdmcp]'''.
  
As SSH affords encrypted authentication and transfers, FTP will be used on our site only for anonymous public downloads. FTP uses fixed port numbers so it is easy to firewall, but it is much slower than NFS. Slackware includes two FTPs : ProFTPd and vsFTP. We will use the latter. Using vsFTP requires very little configuration : setting the home directory of the ftp user to where we want our files to be downloaded from, uncommenting the correct '''ftp''' line in '''/etc/inetd.conf''' and '''/etc/rc.d/rc.inetd restart''', updating the firewall rules. For more details '''man vsftpd.conf'''.
+
To be able to connect as root, update '''/etc/kde/kdm/kdmrc''', specifying '''AllowRootLogin=true''' for '''[X-*-Core]'''.
 
# usermod --home /var/pub ftp
 
. . .
 
# Very Secure File Transfer Protocol (FTP) server.
 
ftp    stream  tcp    nowait  root    /usr/sbin/tcpd  vsftpd
 
. . .
 
# /etc/rc.d/rc.inetd restart
 
. . .
 
# services on local network FTP BOOTP HTTP NNTP IMAP HTTPS SUBMIT VNC VOIP
 
iptables -A INPUT -p tcp -j ACCEPT --dport 20 -m conntrack --ctstate NEW -s 192.168.53.0/24
 
iptables -A INPUT -p tcp -j ACCEPT --dport 21 -m conntrack --ctstate NEW -s 192.168.53.0/24
 
  
== Putting the Slackware install files online ==
+
In '''/etc/kde/kdm/Xaccess''', uncomment line  '''#* # any host can get a login window''' to authorize connection from any incoming IP address (or to restrict usage to your local network).
  
Copy the content of the slackware DVD to a disk directory, for instance '''/var/pub/slackware64-15.0'''
+
== Xdm ==
  
# mkdir /mnt/dvd
+
In '''/etc/X11/xdm/xdm-config''', comment out the line '''#DisplayManager.requestPort:    0''' to authorize X terminal access from the network. Else port 177 won't be listened, as can be verified using '''nmap -sU localhost''', that lists the listening UDP ports. If checking with tcpdump, '''udp port xdmcp unreachable''' will be seen on the wire.
# mkdir /var/pub/slackware64-15.0
 
# mount -o loop slackware64-15.0-install-dvd.iso /mnt/dvd
 
# cp -a /mnt/dvd/* /var/pub/slackware64-15.0/
 
# umount /mnt/dvd
 
  
During install, when asked for the source directory specify subdirectory '''slackware64''' that is, '''/var/pub/slackware64-15.0/slackware64'''
+
In '''/etc/X11/xdm/Xaccess''', uncomment line  '''#* # any host can get a login window''' to authorize connection from any incoming IP address (or to restrict usage to your local network). In '''/etc/X11/xdm/Xservers''', comment out the line with ''':0''' to avoid getting an X login screen on the console.
  
The Slackware network setup uses NFS version 3 meaning that directory paths are absolute.
+
To automatically launch '''xdm''' during Slackware init, add the following lines to '''/etc/rc.d/rc.local''' :
  
== Configuring TFTPBOOT ==
+
  # Xdm
 
+
  if [ -x /usr/X11/bin/xdm ]; then
TFTP is the trivial ftp protocol (for use on a local network). Let's create the '''tftp bootp''' file structure under the default '''/tftpboot''' directory. The directory where we store the bootloader files is '''/tftpboot/slackware64-15.0''' :
+
         /usr/X11/bin/xdm
 
 
# mkdir /tftpboot
 
# mkdir /tftpboot/slackware64-15.0
 
# mkdir /tftpboot/slackware64-15.0/pxelinux.cfg
 
# cp /usr/share/syslinux/pxelinux.0 /tftpboot/slackware64-15.0/
 
# cp /var/pub/slackware64-15.0/isolinux/message.txt /tftpboot/slackware64-15.0/
 
# cp /var/pub/slackware64-15.0/isolinux/f2.txt /tftpboot/slackware64-15.0/
 
  # cp -a /var/pub/slackware64-15.0/kernels /tftpboot/slackware64-15.0/
 
  # cp /var/pub/slackware64-15.0/usb-and-pxe-installers/pxelinux.cfg_default /tftpboot/slackware64-15.0/pxelinux.cfg/default
 
# cp /var/pub/slackware64-15.0/isolinux/initrd.img /tftpboot/slackware64-15.0/
 
 
 
Tftpboot is handled by '''inetd'''. To activate it, uncomment the tftp line in '''/etc/inetd.conf''' then '''/etc/rc.d/rc.inetd restart''' or reboot.
 
 
 
tftp  dgram  udp    wait    root    /usr/sbin/in.tftpd  in.tftpd -s /tftpboot -r blksize
 
 
 
== Configuring DHCP ==
 
 
 
We configure '''/etc/dhcpd.conf''' as follows. Our subnet is '''192.168.53.0''', our network mask '''255.255.255.0''', our IP address is '''192.168.53.1''', our router address '''192.168.53.254'''. The IP DHCP range is '''192.168.53.154''' to '''192.168.53.253'''. For more details on other configuration possbilities, '''man dhcpd.conf'''.
 
 
 
# dhcpd.conf
 
#
 
# Configuration file for ISC dhcpd (see 'man dhcpd.conf')
 
#
 
 
# If this DHCP server is the official DHCP server for the local
 
# network, the authoritative directive should be uncommented.
 
authoritative;
 
ddns-update-style none;
 
 
# Allow bootp requests
 
allow bootp;
 
 
# Point to the TFTP server:
 
next-server 192.168.53.1;
 
 
# Default lease is 1 week (604800 sec.)
 
default-lease-time 604800;
 
# Max lease is 4 weeks (2419200 sec.)
 
max-lease-time 2419200;
 
 
subnet 192.168.53.0 netmask 255.255.255.0 {
 
    option domain-name "studioware.com";
 
    option broadcast-address 192.168.53.255;
 
    option subnet-mask 255.255.255.0;
 
    option domain-name-servers 192.168.53.1;
 
    option routers 192.168.53.254;
 
    range dynamic-bootp 192.168.53.154 192.168.53.253;
 
    use-host-decl-names on;
 
    if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
 
      filename "/slackware64-15.0/pxelinux.0";
 
    }
 
}
 
 
 
Next is to create a script '''/etc/rc.d/rc.dhcpd''' to launch dhcp. Our bridged interface is '''br0''' :
 
 
 
#!/bin/sh
 
#
 
# /etc/rc.d/rc.dhcpd
 
#      This shell script takes care of starting and stopping
 
#      the ISC DHCPD service
 
#
 
 
# Put the command line options here that you want to pass to dhcpd:
 
DHCPD_OPTIONS="-q '''br0'''"
 
 
[ -x /usr/sbin/dhcpd ] || exit 0
 
 
[ -f /etc/dhcpd.conf ] || exit 0
 
 
start() {
 
      # Start daemons.
 
      echo -n "Starting dhcpd:  /usr/sbin/dhcpd $DHCPD_OPTIONS "
 
      /usr/sbin/dhcpd $DHCPD_OPTIONS
 
      echo
 
}
 
stop() {
 
      # Stop daemons.
 
      echo -n "Shutting down dhcpd: "
 
      killall -TERM dhcpd
 
      echo
 
}
 
status() {
 
  PIDS=$(pidof dhcpd)
 
  if [ "$PIDS" == "" ]; then
 
    echo "dhcpd is not running!"
 
  else
 
    echo "dhcpd is running at pid(s) ${PIDS}."
 
  fi
 
}
 
restart() {
 
      stop
 
      start
 
}
 
 
# See how we were called.
 
case "$1" in
 
  start)
 
        start
 
        ;;
 
  stop)
 
        stop
 
        ;;
 
  restart)
 
         stop
 
        start
 
        ;;
 
  status)
 
        status
 
        ;;
 
  *)
 
        echo "Usage: $0 {start|stop|status|restart}"
 
        ;;
 
esac
 
 
exit 0
 
 
 
Next is to make '''/etc/rc.d/rc.dhcpd''' executable, launch it from '''/etc/rc.d/rc.local''' and stop it from '''/etc/rc.d/rc.local_shutdown''' :
 
 
 
# chmod u+x rc.dhcpd
 
. . .
 
# start dhcpd
 
if [ -x /etc/rc.d/rc.dhcpd ]; then
 
        /etc/rc.d/rc.dhcpd start
 
fi
 
. . .
 
# stop dhcpd
 
if [ -x /etc/rc.d/rc.dhcpd ]; then
 
    /etc/rc.d/rc.dhcpd stop
 
 
  fi
 
  fi
  
== Firewalling NFS ==
+
== X11 firewalling ==
 
 
Refer to [[IPTables]] for an introduction on packet filtering. NFS uses some random ports by defaults, that we need to fix if we want to be able to do proper packet filtering. To be precise, NFS uses sunrpc/111 and nfsd/2049, and random port numbers are used by other NFS daemons but it is possible to specify alternative port numbers on the command line or in the '''/etc/services''' file, to which we add :
 
 
 
rpc.nfs-cb      32764/tcp  # RPC nfs callback
 
rpc.nfs-cb      32764/udp  # RPC nfs callback
 
status          32765/udp  # NFS status (listen)
 
status          32765/tcp  # NFS status (listen)
 
status          32766/udp  # NFS status (send)
 
status          32766/tcp  # NFS status (send)
 
mountd          32767/udp  # NFS mountd
 
mountd          32767/tcp  # NFS mountd
 
lockd          32768/udp  # NFS lock daemon/manager
 
lockd          32768/tcp  # NFS lock daemon/manager
 
rquotad        32769/udp  # NFS rquotad
 
rquotad        32769/tcp  # NFS rquotad
 
 
 
The '''/etc/rc.d/rc.nfsd''' and '''/etc/rc.d/rc.rpc''' scripts are modified to specify port numbers on the command lines :
 
 
 
if [ -x /usr/sbin/rpc.rquotad ]; then
 
  echo "  /usr/sbin/rpc.rquotad '''-p 32769'''"
 
  /usr/sbin/rpc.rquotad '''-p 32769'''
 
fi
 
 
if [ -x /usr/sbin/rpc.mountd ]; then
 
  echo "  /usr/sbin/rpc.mountd '''-p 32767'''"
 
  /usr/sbin/rpc.mountd '''-p 32767'''
 
fi
 
 
if ! ps axc | grep -q rpc.statd ; then
 
  echo "Starting RPC NSM (Network Status Monitor):  /sbin/rpc.statd '''-p 32765 -o 32766'''"
 
  /sbin/rpc.statd '''-p 32765 -o 32766'''
 
fi
 
  
To make the lock daemon listen on port '''32768''' only and set the nfs callback port to '''32764''' we need to create file '''/etc/sysctl.d/nfs.conf''' :
+
At the firewall level, the X terminal must be able to contact the host using '''UDP 177''' and the host must be able to callback the X terminal using '''TCP 6000:6063'''. Open the corresponding ports, but to avoid login information to be sent over the wire, restrict usage to the local network :
  
  fs.nfs.nlm_udpport=32768
+
  # SSH-tunnelled X-Window output appears as input on interface lo
  fs.nfs.nlm_tcpport=32768
+
iptables -A INPUT -p udp -j ACCEPT --dport 177 -s 192.168.0.0/24
  fs.nfs.nfs_callback_tcpport=32764
+
  iptables -A INPUT -p tcp -j ACCEPT --dport 6000:6063 -m state --state NEW -s 192.168.0.0/24
 +
  iptables -A INPUT -i lo -p tcp -j ACCEPT --dport 6000:6063 -m state --state NEW -s 192.168.0.0/24
  
Last BOOTP and the NFS ports must be added to '''/etc/rc.d/rc.firewall''' :
+
For access from the Internet, il will be better to encapsulate X11 within an SSH session, using the X11 forwarding option. Due to encryption, this is however much slower. In this case, instead of KDE, prefer a less network-intensive window manager such as xfce4.
 
# BOOTP
 
iptables -A INPUT -p udp -j ACCEPT --dport 69 -s 192.168.53.0/24
 
 
# NFS ports
 
iptables -A INPUT -p udp -j ACCEPT --dport 111 -m conntrack --ctstate NEW -s 192.168.53.0/24
 
iptables -A INPUT -p tcp -j ACCEPT --dport 111 -m conntrack --ctstate NEW -s 192.168.53.0/24
 
iptables -A INPUT -p udp -j ACCEPT --dport 2049 -m conntrack --ctstate NEW -s 192.168.53.0/24
 
iptables -A INPUT -p tcp -j ACCEPT --dport 2049 -m conntrack --ctstate NEW -s 192.168.53.0/24
 
iptables -A INPUT -p udp -j ACCEPT --dport 32764:32769 -m conntrack --ctstate NEW -s 192.168.53.0/24
 
iptables -A INPUT -p tcp -j ACCEPT --dport 32764:32769 -m conntrack --ctstate NEW -s 192.168.53.0/24
 
  
== Slackware setup ==
+
== X11 server ==
  
A few pieces of advice to make your Slackware setup from network easier :
+
The X terminal can be a Linux computer on which you run the X server to display X from a remote client. For instance typing '''nohup X -query <i>host</i> :1 &''' will display X from host <i>host</i> on virtual terminal 8. This way you will be able to keep local X and remote X side by side and switch between them using '''<ctrl><alt><F7>''' and '''<ctrl><alt><F8>'''.
  
* For some reason Slackare might use an interface other than eth0. Just move the cable to the right slot or update (or remove) /etc/udev/rules.d/70-persistent-net.rules.
+
The X terminal can also be a Windows PC equipped with an X emulator such as [https://sourceforge.net/projects/vcxsrv/ VcXrv] or other software found from the Internet. At the time of this writing though, such software is frustrating due to unstability or poor licensing conditions, so VcXrv seems to currently be the better choice, although a bit slow. <u>'''Note'''</u> : Specify in the configuration that you will be using XDMCP.
  
* Slackware network setup uses NFS version 3 meaning that directory paths are absolute. For instance /var/pub/slackware64-15.0/slackware64.
+
== Windows firewall ==
  
* The FTP directory paths are instead relative to the ftp user home directory.
+
On Windows, use the firewall with «'''Allow exceptions'''» and create an entry in the firewall for the X11 protocol (port 6000), specifying in the scope the server IP address or the local network (not the Internet).
  
 
<br/>
 
<br/>
  
{{pFoot|[[Managing partitions]]|[[Main Page]]|[[Installing Slackware]]}}
+
{{pFoot|[[X11 configuration]]|[[Main Page]]|[[Compiling the Kernel]]}}

Latest revision as of 10:55, 29 March 2026

Using X over the network affords accessing remote servers graphically as if you were on the console. So for instance, from your Windows workstation, you can run Windows and Linux side by side, full screen, and switch with function-key combinations such as alt-tab or ctrl-alt-F7 or F8. A very handy feature. X is natively present and fast on Linux. On Windows, it will always be a bit slower, and you need to install an X server. VcXrv is a very competent one.

The software presenting an X window on a terminal is called an X server, which is contrary to what we are used to, as the X server is not on the server but actually on the client ! Over the Internet, you will always encapsulate X11 in SSH (X11 forwarding, to configure in /etc/ssh/sshd_config) as the X protocols are not secure. However, X needs a significant bandwidth so it is not likely that you will use it over an ADSL connection as it would be too slow. Optical fiber could be OK though.

For more information on using remote X applications, check this mini-HOWTO or this excellent O'Reilly book.

Xdm, Kdm, Gdm

X requires a daemon on the server to handle connections. The base daemon is Xdm, that offers a graphical login directly under X, with no desktop manager. Access can be local on the computer console, or can be from an X terminal or X emulated terminal on the network.

The KDE and Gnome desktop environments Kdm and Gdm come with Xdm variants that have a different look and feel. It is possible to run one or several of the three, provided that they will not compete for management of the same terminals.

However it makes sense to use only one. Kdm is a good choice as it affords choosing the Session Window Manager (Kde, Xfce4, ...) from the connection dialog box.

Kdm

For KDE to manage X terminals over the network, update /etc/kde/kdm/kdmrc specifying Enable=true for [Xdmcp].

To be able to connect as root, update /etc/kde/kdm/kdmrc, specifying AllowRootLogin=true for [X-*-Core].

In /etc/kde/kdm/Xaccess, uncomment line #* # any host can get a login window to authorize connection from any incoming IP address (or to restrict usage to your local network).

Xdm

In /etc/X11/xdm/xdm-config, comment out the line #DisplayManager.requestPort: 0 to authorize X terminal access from the network. Else port 177 won't be listened, as can be verified using nmap -sU localhost, that lists the listening UDP ports. If checking with tcpdump, udp port xdmcp unreachable will be seen on the wire.

In /etc/X11/xdm/Xaccess, uncomment line #* # any host can get a login window to authorize connection from any incoming IP address (or to restrict usage to your local network). In /etc/X11/xdm/Xservers, comment out the line with :0 to avoid getting an X login screen on the console.

To automatically launch xdm during Slackware init, add the following lines to /etc/rc.d/rc.local :

# Xdm
if [ -x /usr/X11/bin/xdm ]; then
        /usr/X11/bin/xdm
fi

X11 firewalling

At the firewall level, the X terminal must be able to contact the host using UDP 177 and the host must be able to callback the X terminal using TCP 6000:6063. Open the corresponding ports, but to avoid login information to be sent over the wire, restrict usage to the local network :

# SSH-tunnelled X-Window output appears as input on interface lo
iptables -A INPUT -p udp -j ACCEPT --dport 177 -s 192.168.0.0/24
iptables -A INPUT -p tcp -j ACCEPT --dport 6000:6063 -m state --state NEW -s 192.168.0.0/24
iptables -A INPUT -i lo -p tcp -j ACCEPT --dport 6000:6063 -m state --state NEW -s 192.168.0.0/24

For access from the Internet, il will be better to encapsulate X11 within an SSH session, using the X11 forwarding option. Due to encryption, this is however much slower. In this case, instead of KDE, prefer a less network-intensive window manager such as xfce4.

X11 server

The X terminal can be a Linux computer on which you run the X server to display X from a remote client. For instance typing nohup X -query host :1 & will display X from host host on virtual terminal 8. This way you will be able to keep local X and remote X side by side and switch between them using <ctrl><alt><F7> and <ctrl><alt><F8>.

The X terminal can also be a Windows PC equipped with an X emulator such as VcXrv or other software found from the Internet. At the time of this writing though, such software is frustrating due to unstability or poor licensing conditions, so VcXrv seems to currently be the better choice, although a bit slow. Note : Specify in the configuration that you will be using XDMCP.

Windows firewall

On Windows, use the firewall with «Allow exceptions» and create an entry in the firewall for the X11 protocol (port 6000), specifying in the scope the server IP address or the local network (not the Internet).


X11 configuration Main Page Compiling the Kernel