Re: FAI performance
> On Fri, 21 Sep 2012 20:42:35 +0200, Katarzyna Myrek > said: > Today I was wondering... How many clients can you install > simultaneously? A lot. Some years ago I could install about 20 machines simultaneously when using fast ethernet without any problems. NFS is not a problem, when doing installations with FAI. Maybe your network card is fully stretched and therefor the server seems to be unresponsive. -- regards Thomas
Re: FAI performance
Thomas Lange writes: > > On Fri, 21 Sep 2012 20:42:35 +0200, Katarzyna Myrek > > said: > > > Today I was wondering... How many clients can you install > > simultaneously? > A lot. Some years ago I could install about 20 machines simultaneously > when using fast ethernet without any problems. NFS is not a problem, > when doing installations with FAI. Maybe your network card is > fully stretched and therefor the server seems to be unresponsive. > > -- > regards Thomas 70 clients at once with 10Gbps interface is no problem. Best wishes Andreas
Re: FAI performance
> On Fri, 21 Sep 2012 22:06:27 +0200, Michał Dwużnik > said: > by the way - what are the default options of mounting the NFS by FAI when installing? > (rsize in particular, atime?) Using a squeeze install server and FAI 3.4.8 I get these NFS parameters from cat /proc/mounts 1.2.3.149:/srv/fai/nfsroot-squeeze64 /live/image nfs ro,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nolock,proto=tcp,port=65535,timeo=7,retrans=3,sec=sys,mountport=65535,addr=1.2.3.149 0 0 IMO there's no need to set the rsize parameter. -- regards Thomas
Re: FAI performance
Le 24/09/2012 14:03, Thomas Lange a écrit : On Fri, 21 Sep 2012 22:06:27 +0200, Michał Dwużnik said: > by the way - what are the default options of mounting the NFS by FAI when installing? > (rsize in particular, atime?) Using a squeeze install server and FAI 3.4.8 I get these NFS parameters from cat /proc/mounts 1.2.3.149:/srv/fai/nfsroot-squeeze64 /live/image nfs ro,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nolock,proto=tcp,port=65535,timeo=7,retrans=3,sec=sys,mountport=65535,addr=1.2.3.149 0 0 IMO there's no need to set the rsize parameter. I had to do so to install a few hosts through a 10 Mb/s WAN : rsize=65536,wsize=65536. Higher values lead to frequent NFS time-outs. -- Nicolas
Re: FAI performance
Well, in my not quite so 10GbE env I experience NFS timeouts when doing 16 machines at a time. Moving the fai configspace onto ramdisk helps for the rooms equipped with 1Gbps, yields _lots_ of 'NFS not responding, still trying' for one forgotten room which has still has 100Mbit Hence my original question (which seems to be in line with Nicolas Courtel experience) Regards Michal On Mon, Sep 24, 2012 at 2:03 PM, Thomas Lange wrote: > > On Fri, 21 Sep 2012 22:06:27 +0200, Michał Dwużnik < > michal.dwuz...@gmail.com> said: > > > by the way - what are the default options of mounting the NFS by FAI > when installing? > > (rsize in particular, atime?) > Using a squeeze install server and FAI 3.4.8 I get these NFS > parameters from cat /proc/mounts > > 1.2.3.149:/srv/fai/nfsroot-squeeze64 /live/image nfs > ro,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nolock,proto=tcp,port=65535,timeo=7,retrans=3,sec=sys,mountport=65535,addr=1.2.3.149 > 0 0 > > IMO there's no need to set the rsize parameter. > > -- > regards Thomas > -- Michal Dwuznik
Re: FAI performance
Sounds to me like you have a network issue, NFS timeouts shouldn't occur unless there are lost packets -- if the disk is stuck in I/O wait the NFS process can still respond. Check your interfaces and switches for dropped/errored packets. You should be able to host hundreds of clients off a 1G, it would just be slower. The fai NFS config space hosts very little data, most of the action is spent transferring the .deb's via HTTP, and not NFS. Each step only requires reading in a couple small files (class definitions, .var files, scripts) and it would take an obscene amount of hosts accessing these small files to use up a 10g link. If your config space is over a meg in total, I'd be surprised. This is not the issue. I have some large tarballs in mine (a few gig) and it moves along smoothly with 100 nodes going at once. On Mon, Sep 24, 2012 at 9:06 AM, Michał Dwużnik wrote: > Well, > > in my not quite so 10GbE env I experience NFS timeouts when doing 16 > machines at a time. > Moving the fai configspace onto ramdisk helps for the rooms equipped with > 1Gbps, > yields _lots_ of 'NFS not responding, still trying' for one forgotten room > which has still has 100Mbit > > Hence my original question (which seems to be in line with Nicolas > Courtel experience) > > Regards > Michal > > > > > > On Mon, Sep 24, 2012 at 2:03 PM, Thomas Lange < > la...@informatik.uni-koeln.de> wrote: > >> > On Fri, 21 Sep 2012 22:06:27 +0200, Michał Dwużnik < >> michal.dwuz...@gmail.com> said: >> >> > by the way - what are the default options of mounting the NFS by >> FAI when installing? >> > (rsize in particular, atime?) >> Using a squeeze install server and FAI 3.4.8 I get these NFS >> parameters from cat /proc/mounts >> >> 1.2.3.149:/srv/fai/nfsroot-squeeze64 /live/image nfs >> ro,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nolock,proto=tcp,port=65535,timeo=7,retrans=3,sec=sys,mountport=65535,addr=1.2.3.149 >> 0 0 >> >> IMO there's no need to set the rsize parameter. >> >> -- >> regards Thomas >> > > > > -- > Michal Dwuznik >
Re: FAI performance
> If your config space is over a meg in total, I'd be surprised. This is > not the issue. Color yourself surprised then. You forgot the base-images which easily amount to more then 100 MB each. (I've found them quite useful for installing SuSE-hosts with FAI although you might also use them to 'skip' the debootstrapping stage with Debian/Ubuntu.) bye thomas
Re: FAI performance
> If your config space is over a meg in total, I'd be surprised. This is > not the issue. > > I have some large tarballs in mine (a few gig) and it moves along smoothly > with 100 nodes going at once. > > My config space is indeed in order of 10GB :> Regards Michal
Re: FAI performance
hi,
Am 24.09.2012 um 17:30 schrieb Michał Dwużnik :
> My config space is indeed in order of 10GB :>
you mean where you have files and directories like
"config/{class,debconf,disk_config ...}" ? over 10GB? It sounds like, that you
transfer images etc. so it would be better, to use ftp to transmit the big
files. In my case my config is also lower than 1MB ..
cu denny
Re: on sending a kerberos keytab to the client machine
> On Mon, 3 Sep 2012 22:40:08 +0200, "Andreas B. Mundt" > said: > * Add the MAC addresses of all machines to be installed to > dhcpd.conf. You have to make sure that nobody in the network > can fake a MAC address if you do that by some automatic means. > Did I miss something? Yes. You _can_ fake MAC addresses easily :-( I don't know how to prevent this. Maybe setting fixed MAC addresse on every port of your switch. But this will be a lot of work, and some (or maybe most) switches can be fooled by MAC address flooding. IMO the only really secure way is to enter some secret on every machine, for creating a secure and encrypted communication channel to the install server. But even then, you have to trust into the person how enters the secret on every machine. -- regards Thomas
Re: on sending a kerberos keytab to the client machine
On Mon, September 24, 2012 12:58, Thomas Lange wrote: >> On Mon, 3 Sep 2012 22:40:08 +0200, "Andreas B. Mundt" >> said: > > > * Add the MAC addresses of all machines to be installed to > > dhcpd.conf. You have to make sure that nobody in the network > > can fake a MAC address if you do that by some automatic means. > > > Did I miss something? > > Yes. You _can_ fake MAC addresses easily :-( > I don't know how to prevent this. Maybe setting fixed MAC addresse on > every port of your switch. But this will be a lot of work, and some > (or maybe most) switches can be fooled by MAC address flooding. Not necessarily a lot of work. Some switches allow you to specify the maximum number of MAC address on a switch (auto-learning them), and once that number has been reached, no other MACs will be paid attention to: http://www.hp.com/rnd/device_help/help/hpwnd/webhelp/HPJ4121A/security_perports.htm http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sg/configuration/guide/port_sec.html#wp1070234 This still doesn't solve MAC spoofing, but it tends to be an obscure enough feature that for the "casual attacker" it will throw a reasonable curve ball. At the end of the day, if you need to really be secure, you need to have some kind of state on the client machine (Kerberos password, 802.1x credentials, etc.)--which generally doesn't exist on a clean image.
Re: FAI performance
Hi,
The first (and seemingly correct) approach is to use fcopy, without mixing
yet another protocol into the mix. FTP/HTTP/NFS seem to me of 'the same
class' and fcopy was (I admit) the easiest to setup by copying the ready
made skeletons-> I tried it for the first approach, as an ultimate step
forward I'm thinking more of a bittorrent seeder for the 'big tarfiles to
unpack on clients'...
Regards
Michal
On Mon, Sep 24, 2012 at 6:28 PM, Denny Schierz wrote:
> hi,
>
> Am 24.09.2012 um 17:30 schrieb Michał Dwużnik :
>
> > My config space is indeed in order of 10GB :>
>
> you mean where you have files and directories like
> "config/{class,debconf,disk_config ...}" ? over 10GB? It sounds like, that
> you transfer images etc. so it would be better, to use ftp to transmit the
> big files. In my case my config is also lower than 1MB ..
>
> cu denny
--
Michal Dwuznik
Re: on sending a kerberos keytab to the client machine
Hi, > At the end of the day, if you need to really be secure, you need to have > some kind of state on the client machine (Kerberos password, 802.1x > credentials, etc.)--which generally doesn't exist on a clean image. > > > 'Clean image' runs on a particular machine which, it seems to me, can be fingerprinted before. For some machines there will be the vendor serial/service tag available, for some there will be e.g. memory module serial or disk serial number. Combination of e.g. service tag, disk serial number and memory module serials seems reasonably close to being unique and immutable. Regards Michal Michal
