AutoYaST and firewall configuration
Hi everyone,
I'm currently playing with AutoYaST on a scratch system, with a view to
using SuSE 9.0+AutoYAST in place of Redhat 9+Kickstart on some of our
servers. AutoYaST works rather nicely, but I'm having a couple of teething
problems which is probably down to ignorance on my part.
My test install environment is based on the GRUB boot floppy found at:
ftp://ftp.suse.com/pub/people/nashif/autoinstall/
I'm looking at an install environment which uses TFTP for boot images and
autoyast files but which uses manually configured IP addresses supplied by
the grub and autoyast configurations. I don't trust DHCP on our network,
simply because of the large numbers of different groups who run servers.
Problem #1: Spurious DHCP requests
==================================
Unless I switch off forceboot and reboot in the autoyast.xml file:
<mode>
<confirm config:type="boolean">true</confirm>
<forceboot config:type="boolean">false</forceboot>
<reboot config:type="boolean">false</reboot>
</mode>
the system reboots and attempts a DHCP lookup on eth0 before setting up
the static IP address which I have specified in the autoyast.xml file:
<networking>
...
<interfaces config:type="list">
<interface>
<bootproto>static</bootproto>
<broadcast>131.111.255.255</broadcast>
<device>eth0</device>
<ipaddr>131.111.11.209</ipaddr>
<netmask>255.255.0.0</netmask>
<network>131.111.0.0</network>
<startmode>onboot</startmode>
</interface>
</interfaces>
...
</networking>
Is there another way of stopping the redundant DHCP request? At best this
leads to a delay until the request times out. At worse the machine could
end up with an invalid configuration.
Problem #2: Firewall configuration
==================================
/sbin/yast2 autoyast provides a screen for configurating a firewall
which generates the following in autoyast.xml:
<firewall>
David Carter wrote:
Hi everyone,
I'm currently playing with AutoYaST on a scratch system, with a view to using SuSE 9.0+AutoYAST in place of Redhat 9+Kickstart on some of our servers. AutoYaST works rather nicely, but I'm having a couple of teething problems which is probably down to ignorance on my part.
My test install environment is based on the GRUB boot floppy found at:
ftp://ftp.suse.com/pub/people/nashif/autoinstall/ And in 9.0 documentation there is a section describing how to create such a boot floppy using the latest GRUB from 9.0...
I'm looking at an install environment which uses TFTP for boot images and autoyast files but which uses manually configured IP addresses supplied by the grub and autoyast configurations. I don't trust DHCP on our network, simply because of the large numbers of different groups who run servers.
Problem #1: Spurious DHCP requests ==================================
Unless I switch off forceboot and reboot in the autoyast.xml file:
<mode> <confirm config:type="boolean">true</confirm> <forceboot config:type="boolean">false</forceboot> <reboot config:type="boolean">false</reboot> </mode>
the system reboots and attempts a DHCP lookup on eth0 before setting up the static IP address which I have specified in the autoyast.xml file:
<networking> ... <interfaces config:type="list"> <interface> <bootproto>static</bootproto> <broadcast>131.111.255.255</broadcast> <device>eth0</device> <ipaddr>131.111.11.209</ipaddr> <netmask>255.255.0.0</netmask> <network>131.111.0.0</network> <startmode>onboot</startmode> </interface> </interfaces> ... </networking>
Is there another way of stopping the redundant DHCP request? At best this leads to a delay until the request times out. At worse the machine could end up with an invalid configuration.
Hmm, this should not happen. Can you check the file /var/lib/YaST2/install.inf and see if the network values you have supplied are present there!
Problem #2: Firewall configuration ==================================
/sbin/yast2 autoyast provides a screen for configurating a firewall which generates the following in autoyast.xml:
<firewall>
yes yes eth0 no yes no yes no yes no ssh true </firewall>The yast postinstall script which runs says "Setting up firewall", and there is various output in y2log which includes:
2003-12-08 12:38:45 <1> magenta-4(2667) [YCP] clients/autoinst_configure.ycp:105 Writing configuration for firewall
However, /etc/sysconfig/SuSEfirewall2 doesn't appear to get updated:
-rw-r--r-- 1 root root 26770 Dec 8 12:35 SuSEfirewall2
and iptables doesn't acquire any rules. Does autoyast support SuSEfirewall yet? It is conspicuous by its absence in the documentation provided at:
Ok, I might need to run a test install and see what exactly happens there.. Anas
Thanks in advance for any answers.
On Wed, 10 Dec 2003, Anas Nashif wrote:
Is there another way of stopping the redundant DHCP request? At best this leads to a delay until the request times out. At worse the machine could end up with an invalid configuration.
Hmm, this should not happen. Can you check the file /var/lib/YaST2/install.inf and see if the network values you have supplied are present there!
menu.lst on GRUB floppy includes: title autoinstall ifconfig --address=131.111.11.209 --server=131.111.10.90 root (nd) kernel (nd)/suse/linux \ hostip=131.111.11.209 netmask=255.255.0.0 \ gateway=131.111.11.62 nameserver=131.111.8.42 \ install=nfs://131.111.8.10/linux/suse/i386/9.0 \ autoyast=tftp://131.111.10.90/suse/autoyast.xml \ textmode=1 initrd (nd)/suse/initrd /var/lib/YaST2/install.inf on installed system includes: NetConfig: static Netdevice: eth0 NetUniqueID: 7EWs.weGuQ9ywYPF IP: 131.111.11.209 Hostname: 131.111.11.209 Broadcast: 131.111.255.255 Network: 131.111.0.0 Netmask: 255.255.0.0 Gateway: 131.111.11.62 Nameserver: 131.111.8.42 Server: 131.111.8.10 /var/log/messages right after first reboot: Dec 8 12:38:16 linux dhcpcd[2782]: broadcasting DHCP_DISCOVER Dec 8 12:38:26 linux dhcpcd[2782]: timed out waiting for a valid DHCP server response /etc/sysconfig/network/ifcfg-eth0 is created a few seconds later by the autoinst postinstall script: -rw-r--r-- 1 root root 160 2003-12-08 12:38:41.000000000 +0000 /etc/sysconfig/network/ifcfg-eth0 and contains: BOOTPROTO='static' BROADCAST='131.111.255.255' IPADDR='131.111.11.209' NETMASK='255.255.0.0' NETWORK='131.111.0.0' STARTMODE='onboot' UNIQUE='7EWs.weGuQ9ywYPF' ifcfg-eth0 doesn't exist before that point in time. -- David Carter Email: David.Carter@ucs.cam.ac.uk University Computing Service, Phone: (01223) 334502 New Museums Site, Pembroke Street, Fax: (01223) 334679 Cambridge UK. CB2 3QH.
Op Thursday 11 December 2003 12:14, schreef David Carter: DC> On Wed, 10 Dec 2003, Anas Nashif wrote: DC> DC> > > Is there another way of stopping the redundant DHCP request? At best this DC> > > leads to a delay until the request times out. At worse the machine could DC> > > end up with an invalid configuration. DC> > > DC> > Hmm, this should not happen. Can you check the file DC> > /var/lib/YaST2/install.inf DC> > and see if the network values you have supplied are present there! DC> DC> menu.lst on GRUB floppy includes: DC> DC> title autoinstall DC> ifconfig --address=131.111.11.209 --server=131.111.10.90 DC> root (nd) DC> kernel (nd)/suse/linux \ DC> hostip=131.111.11.209 netmask=255.255.0.0 \ DC> gateway=131.111.11.62 nameserver=131.111.8.42 \ DC> install=nfs://131.111.8.10/linux/suse/i386/9.0 \ DC> autoyast=tftp://131.111.10.90/suse/autoyast.xml \ DC> textmode=1 DC> initrd (nd)/suse/initrd DC> DC> /var/lib/YaST2/install.inf on installed system includes: DC> DC> NetConfig: static DC> Netdevice: eth0 DC> NetUniqueID: 7EWs.weGuQ9ywYPF DC> IP: 131.111.11.209 DC> Hostname: 131.111.11.209 DC> Broadcast: 131.111.255.255 DC> Network: 131.111.0.0 DC> Netmask: 255.255.0.0 DC> Gateway: 131.111.11.62 DC> Nameserver: 131.111.8.42 DC> Server: 131.111.8.10 DC> DC> /var/log/messages right after first reboot: DC> DC> Dec 8 12:38:16 linux dhcpcd[2782]: broadcasting DHCP_DISCOVER DC> Dec 8 12:38:26 linux dhcpcd[2782]: DC> timed out waiting for a valid DHCP server response What is in the DHCP server logs about this DHCP request? I had a similar problem in my small home network (2 pc's), where the dhcp lease was not released just before the first reboot. Obviously the freshly installed OS can *not* now that there already is a lease waiting for it. My solution was to stop the dhcp-server, remove the lease, and start the dhcp-server again. Any scripts run during installation before the first reboot are run in a chrooted environment, and thus cannot influence the install program. Cheers, Leen
participants (3)
-
Anas Nashif
-
David Carter
-
Leendert Meyer