FAIBASE/10-misc and hostname
Hi all, I stumbled over FAIBASE/10-misc and setting of the hostname. This has changed in FAI-4, in earlier versions there was something like: fcopy /etc/hostname || echo $HOSTNAME > $target/etc/hostname The first part is strange (who would fcopy the hostname file?) but the second half would set the hostname during installation based on the given hostname. I have the problem, that the dhcp server is not sending the hostname (and I can't change this) and so I set it on the append line used by PXE-boot. But with 4.0 I am now ending up with hostname (none), which is not a good starting point for class definition... No question, this is easy to fix. But maybe someone else has the same problem? Wouldn't it be a good idea to gather all the pitfalls and put it on a Tips&Tricks Webpage? Best regards Dirk -- +--+ | Dr. Dirk Geschke / Plankensteinweg 61/ 85435 Erding| | Telefon: 08122-559448 / Mobil: 0176-96906350 / Fax: 08122-9818106 | | d...@geschke-online.de / d...@lug-erding.de / kont...@lug-erding.de | +--+
Re: FAIBASE/10-misc and hostname
On Monday 11 March 2013 09:31:08 Dirk Geschke wrote: > I stumbled over FAIBASE/10-misc and setting of the hostname. This > has changed in FAI-4, in earlier versions there was something like: > >fcopy /etc/hostname || echo $HOSTNAME > $target/etc/hostname > > The first part is strange (who would fcopy the hostname file?) You could define a class, create an appropriate hostname file for the class and let fcopy figure out the correct file to copy. E.g. you could query a database for the correct hostname or you could provide the class via the kernel command line (ADDCLASSES=xxx,yyy). For a networkless installation from cd it could be sufficient to create files/etc/hostname/FAICD with content 'liveboot'. [...] > Wouldn't it be a good idea to gather all the pitfalls and put it > on a Tips&Tricks Webpage? [This is just my personal interpretation, nothing official.] I guess this and other 'issues' stem from misusing the 'simple' example. It's really just that, it's an example. It's not a reference impementation. But it is used as such. (I don't blame anybody for this 'misusage'. It's just the way it is.) The problem is there's no implied guarantee that the fai 3.x example is compatible to the 4.x config space example. It's just an example. Regarding Tips&Tricks - there is something like that already -> http://wiki.fai-project.org/wiki/Howtos Is this what you were thinking of? Maybe it's just not featured enough? If you know what you're looking for, then you find it - if you don't know it is there it's very easily missable. http://fai-project.org/ -> Documentation -> The FAI wiki -> (User contributed in this wiki) HowTos But apart from that - maybe we should reorganize this somewhat. We have a lowlevel description about the FAI config space concept and what each stage is doing (FAI manual, chapter 8) and we have advanced documentation which provides detailed information on very specific topics (like multiboot), but it seems to me the 'in between' is missing and is filled solely by the configspace example. This is perfectly illustrated by the FAI manual: Chapter 8 - Installation details Chapter 9 - How to build a Beowulf cluster using FAI I think there's at least room for a chapter 8.5 - 'Your first fai installation / config space' and maybe even chapter 8.6 - Troubleshooting Other thoughts? bye thomas
Re: FAIBASE/10-misc and hostname
Hi Thomas, > > I stumbled over FAIBASE/10-misc and setting of the hostname. This > > has changed in FAI-4, in earlier versions there was something like: > > > >fcopy /etc/hostname || echo $HOSTNAME > $target/etc/hostname > > > > The first part is strange (who would fcopy the hostname file?) > > You could define a class, create an appropriate hostname file for the class > and let fcopy figure out the correct file to copy. E.g. you could query a > database for the correct hostname or you could provide the class via the > kernel command line (ADDCLASSES=xxx,yyy). For a networkless installation > from cd it could be sufficient to create files/etc/hostname/FAICD with > content 'liveboot'. hm, sounds complicated to get the right hostname for each system. However, it is no longer part of the example script. > [...] > > Wouldn't it be a good idea to gather all the pitfalls and put it > > on a Tips&Tricks Webpage? > > [This is just my personal interpretation, nothing official.] > > I guess this and other 'issues' stem from misusing the 'simple' example. > It's really just that, it's an example. It's not a reference impementation. > But it is used as such. (I don't blame anybody for this 'misusage'. It's > just the way it is.) The problem is there's no implied guarantee that the > fai 3.x example is compatible to the 4.x config space example. It's just an > example. That's the point. I started to use 4.x instead of 3.x. Since I expected some changes (improvements?) I started with the example scripts again. Especially the package files might have changed for wheezy compared to squeeze. Since the old example script worked out-of-the-box, I expected the same for the new one. It is not really a big problem, I found the problem quickly. But maybe someone else will need more time or give just up on this topic? > Regarding Tips&Tricks - there is something like that already -> > http://wiki.fai-project.org/wiki/Howtos Is this what you were thinking of? > Maybe it's just not featured enough? If you know what you're looking for, > then you find it - if you don't know it is there it's very easily missable. Yes and no, I thought more of a collection of mostly short tipps and hints. In this case it would be a hint, what to do if the DHCP server is not telling the hostname to the client. A complete HOWTO for this topic maybe overkill and probably most want find it, I guess. Or think of my last topic: Multi-Arch with amd64 and i386. That would only result in a few lines but it would be helpful to find some lines. The NFSv4 problem is also documented but difficult to find. Or my actual problem: Installing 32-bit iceweasel on a 64-bit system. You can't simply install iceweasel:i386, it would break a lot of other packages and you can't actually install things like xul-ext-noscript, allthough there is only one package for all architectures. (Yes, I need the 32-bit version for thinks like acrobat plugin or adobe flash.) Although, the last point would be enough stuff for a howto... ;-) > http://fai-project.org/ > -> Documentation >-> The FAI wiki > -> (User contributed in this wiki) HowTos Ah, that comes near to what I thought of: Helper scripts. But that shows another problem: I did not find it (quickly)... > But apart from that - maybe we should reorganize this somewhat. We have a > lowlevel description about the FAI config space concept and what each stage > is doing (FAI manual, chapter 8) and we have advanced documentation which > provides detailed information on very specific topics (like multiboot), but > it seems to me the 'in between' is missing and is filled solely by the > configspace example. This is perfectly illustrated by the FAI manual: > Chapter 8 - Installation details > Chapter 9 - How to build a Beowulf cluster using FAI > I think there's at least room for a chapter 8.5 - 'Your first fai > installation / config space' and maybe even chapter 8.6 - Troubleshooting > > Other thoughts? Sounds good, there seems to be a big problem with FAI: The first steps are very cumbersome and I remember the documentation was not very helpful. Afterwards, when I got it up and running, I found nearly all in the documentation... It looks like there is a gap between "beginners" and "advanced users". But I can't say, where it is nor how to fill it... Ah, I remember one point more: $ROOTCMD and $target. As all systems were up and running, the scripts worked very well for maintenace without these variables. But as I tried to install a new system per PXE boot sometime later, all crashed due to AUFS bugs. No question, it was my mistake, but it took long to identify the error in the scripts, since I got error messages from AUFS... Most of the problems where small errors but it was difficult to locate the cause for them. Without a clue one tends to say FAI is buggy, which is not the case. If it is runnig, FAI does a nice job and is extremly flexible! Best regards Dirk -
Re: FAIBASE/10-misc and hostname
Hi Dirk, On Mon, Mar 11, 2013 at 11:17:05AM +0100, Dirk Geschke wrote: [...] > > I guess this and other 'issues' stem from misusing the 'simple' example. > > It's really just that, it's an example. It's not a reference impementation. > > But it is used as such. (I don't blame anybody for this 'misusage'. It's > > just the way it is.) The problem is there's no implied guarantee that the > > fai 3.x example is compatible to the 4.x config space example. It's just an > > example. > > That's the point. I started to use 4.x instead of 3.x. Since I expected > some changes (improvements?) I started with the example scripts again. > Especially the package files might have changed for wheezy compared to > squeeze. > [...] > Sounds good, there seems to be a big problem with FAI: The first steps > are very cumbersome and I remember the documentation was not very helpful. > Afterwards, when I got it up and running, I found nearly all in the > documentation... > > It looks like there is a gap between "beginners" and "advanced users". > But I can't say, where it is nor how to fill it... > I would like to take the chance to point to the Debian-LAN project [1], an attempt to provide a FAI config space [2] which might be used to deploy a full-featured local area network environment based on Debian. Perhaps this 'more complicated' example can be of help and inspiration sometimes. (Probably not in this particular case). Best regards, Andi [1] http://wiki.debian.org/DebianLAN> [2] http://anonscm.debian.org/gitweb/?p=collab-maint/debian-lan.git>
Re: FAIBASE/10-misc and hostname
Hi, Thomas Neumann (FAI) wrote on 2013-03-11 10:24:28 +0100 [Re: FAIBASE/10-misc and hostname]: > [...] > [This is just my personal interpretation, nothing official.] > > I guess this and other 'issues' stem from misusing the 'simple' example. > It's really just that, it's an example. It's not a reference impementation. > But it is used as such. (I don't blame anybody for this 'misusage'. It's > just the way it is.) The problem is there's no implied guarantee that the > fai 3.x example is compatible to the 4.x config space example. It's just an > example. this is actually something I have been wondering about for quite a while. I'm still using the FAIBASE class (and FAI 3.x, for that matter), because it seems to provide some "glue" between FAI and my configuration. Initially, as you say, I believed it just belonged to FAI. By now, I've realized it's not that simple. Quite probably I didn't read the documentation closely enough, but you seem to be saying it would not have clarified the matter anyway :). I'm sorry if it does and my message is just bogus. When installing a basic Debian system (for example), there are a few things to be done aside from "debootstrap", before a specific config space takes over. These are handled by FAI in one way or another. Examples that spring to mind are - partitioning and setting up file systems - setting up sources.list - saving the hostname - saving interface configuration. Some of these are FAI tasks, some are not. You can probably argue about whether hostname and /etc/network/interfaces are the responsibility of FAI or of the config space. Personally, I do partitioning via a hook and not the FAI way. Works fine. FAI is very flexible there. And the FAIBASE examples provide some things any system seems to need (and does some things I don't agree with - which is ok, as I can simply modify the scripts). The question seems to be, what happens with a major version change of FAI? Is there a defined set of things for which FAI is responsible, and everything else, which the config space should do? If this were so, then shouldn't a config space ideally work independent of the FAI version it is running on? I see that apparently some task names have changed in 4.x, so I would obviously have to adapt my config space correspondingly. Ok. But why do the FAIBASE "examples" change? Is this a dependency of the target system to be installed (more setup needed for wheezy than squeeze), or of the situation FAI sets up on its own? Or is it just a change in the example setup that I can just as well ignore? I realize that there are many different ways to achieve the same result. There could be a 'task hostname' and a 'task interfaces', presuming setting up a hostname and configuring interfaces were thought to be integral parts of an installation. Anyone could still do whatever they wanted with hooks and by overwriting or editing the files (as in 'sed' or 'perl -pi' or even cfengine). It's probably simpler to use a script, but doesn't that mean that some generic installation tasks are offloaded to the config space? Where exactly is the border, as defined by FAI? I'm sure Thomas Lange has an excellent grasp of all the steps needed for a successful (Linux) installation and in what order they should be done, and I'm sure there are reasons for what appears to me to be mixing up necessary installation steps and facultative installation steps in a FAIBASE class. I'd just like to understand them :). Regards, Holger
Re: FAIBASE/10-misc and hostname
Hiya [I'm not ~the~ Thomas, but I still want to answer.] On Monday, March 11, 2013 06:15:13 PM Holger Parplies wrote: > Some of these are FAI tasks, some are not. You can probably argue about > whether hostname and /etc/network/interfaces are the responsibility of FAI > or of the config space. Then the wise master nodded and asked the initiate: What is an 'installation'? Sorry, I just had to do it, because this issue felt like it needed a koan. Don't take it personally. > [...] I'm sure there are reasons for what appears to me to be mixing up > necessary installation steps and facultative installation steps in a FAIBASE > class. I'd just like to understand them :). Everything in FAIBASE _is_ optional and depends on your environment: - partition layout (chroot / virtual containers) - pre-seeding (may not even be possible (RPM?)) - packages (base image can contain everything) - mountpoints (chroot / virtual containers) - network interfaces (chroot / virtual containers) - config files (handled via some other config management tool) (The simple example features 2 hooks, but it wouldn't matter much if they were simply left out.) FAI provides a low-level abstraction and the config space is the environment- specific implementation. With the exception of installing a bootloader you can install a standalone client with just a bunch of text files (disk_config, packages, ...) and exactly two commands (fcopy /etc/network/interfaces and the one for setting the root password.) The bootloader issue is pretty nasty though, because the 'correct' configuration is linked very tightly to the installed distribution, your environment and possibly even the underlying 'hardware'. (Installing a paravirtualised XenServer instance was a nightmare, because Citrix did not actually parse the bootloader, but circumvented grub completely instead read the menu.lst directly and expected to find specifically named boot configuration. Took a while to figure that one out...) bye thomas
Re: FAIBASE/10-misc and hostname
mån 2013-03-11 klockan 19:46 +0100 skrev Thomas Neumann: > Hiya > > [I'm not ~the~ Thomas, but I still want to answer.] > > On Monday, March 11, 2013 06:15:13 PM Holger Parplies wrote: > > Some of these are FAI tasks, some are not. You can probably argue about > > whether hostname and /etc/network/interfaces are the responsibility of FAI > > or of the config space. > > Then the wise master nodded and asked the initiate: What is an 'installation'? :-) Why not a step by step guidance from a clean system and then add things to end up with a configuration space with enough to have a resonable system that shown the most important technics that is needed to master when doing fai installation/upgrade? Might be something to work on in the wiki space? I am totally beginner and have just lurked the list to pick some stuff up, but never done a proper installation. Have not had the time for that. :-( /Anders > Sorry, I just had to do it, because this issue felt like it needed a koan. > Don't take it personally. > > [...] I'm sure there are reasons for what appears to me to be mixing up > > necessary installation steps and facultative installation steps in a FAIBASE > > class. I'd just like to understand them :). > > Everything in FAIBASE _is_ optional and depends on your environment: > - partition layout (chroot / virtual containers) > - pre-seeding (may not even be possible (RPM?)) > - packages (base image can contain everything) > - mountpoints (chroot / virtual containers) > - network interfaces (chroot / virtual containers) > - config files (handled via some other config management tool) > > (The simple example features 2 hooks, but it wouldn't matter much if they > were > simply left out.) > > FAI provides a low-level abstraction and the config space is the environment- > specific implementation. With the exception of installing a bootloader you > can > install a standalone client with just a bunch of text files (disk_config, > packages, ...) and exactly two commands (fcopy /etc/network/interfaces and > the > one for setting the root password.) > > The bootloader issue is pretty nasty though, because the 'correct' > configuration is linked very tightly to the installed distribution, your > environment and possibly even the underlying 'hardware'. (Installing a > paravirtualised XenServer instance was a nightmare, because Citrix did not > actually parse the bootloader, but circumvented grub completely instead read > the menu.lst directly and expected to find specifically named boot > configuration. > Took a while to figure that one out...) > > bye > thomas -- Anders Jackson, universitetsadjunkt i datavetenskap, Högskolan i Gävle Tel: 026 6488764 | Fax: 026 648758 | Webb: http://www.hig.se/~jackson/ Rum: 99:533 | Högskolan i Gävle, ATM-akademin, SE-801 76 GÄVLE smime.p7s Description: S/MIME cryptographic signature
Re: FAIBASE/10-misc and hostname
> On Mon, 11 Mar 2013 18:15:13 +0100, Holger Parplies > said: > sure there are reasons for what appears to me to be mixing up necessary > installation steps and facultative installation steps in a FAIBASE class. I'd > just like to understand them :). Hi, FAI major goal was always to be as flexible as possible but also like to give some structure (the tasks and classes) to the user. Most other installation tools define their essential steps (like setting language, keyboard layout, disk patitioning,...) and then it's up to the user to do all optional configuration steps in a self written postinstall script. This is completely flexible but also with not structure. FAI wants to give more help to the user, by defining some tasks and providing the use of FAI classes in all parts of the installation/configuration process. But I never want to make FAI say "This is the (only) way you have to install you computers". So, it's not easy to say which steps are essential or which are optional (and belong to the config space or belong in FAI itself). And therefore some steps may be in the wrong part of FAI. -- regards Thomas
Re: FAIBASE/10-misc and hostname
Hi Thomas, > > Some of these are FAI tasks, some are not. You can probably argue about > > whether hostname and /etc/network/interfaces are the responsibility of FAI > > or of the config space. > > Then the wise master nodded and asked the initiate: What is an 'installation'? > > Sorry, I just had to do it, because this issue felt like it needed a koan. > Don't take it personally. oh, in my case it was just an upgrade von 3.x/squeeze to 4.x/wheezy. I started with 3.x and the quick installation by using the example scripts. This worked finde and I started to define my own classes, scripts etc. Now I migrated to 4.x and I thought - it is a major release change and therefore I expected some conceptual changes - it would be a good way to start the same way as with 3.x: The example scripts. I did not find an upgrade path - probably it would be impossible to write one since FAI is extremly flexible and one can not take care for all possibilities. Maybe a documentation of the changes in the example files might be a good idea. Although, this are example files... But back to me: I did not expect that all will work out-of-the-box. And I found right quickly the cause for my problem. But I guess that there are more people out there with similar problems and maybe they will not find the cause quickly. So maybe a collection of possible issues would be a good idea to start debugging or get hints where to look at. And at this point I think, one could also start to collect some tips and tricks, too. Why should everyone reinvent the wheel? I just found some solutions here: http://wiki.fai-project.org/wiki/Helper_scripts Maybe on can extend this section... > > [...] I'm sure there are reasons for what appears to me to be mixing up > > necessary installation steps and facultative installation steps in a FAIBASE > > class. I'd just like to understand them :). > > Everything in FAIBASE _is_ optional and depends on your environment: > - partition layout (chroot / virtual containers) > - pre-seeding (may not even be possible (RPM?)) > - packages (base image can contain everything) > - mountpoints (chroot / virtual containers) > - network interfaces (chroot / virtual containers) > - config files (handled via some other config management tool) > > (The simple example features 2 hooks, but it wouldn't matter much if they > were > simply left out.) > > FAI provides a low-level abstraction and the config space is the environment- > specific implementation. With the exception of installing a bootloader you > can > install a standalone client with just a bunch of text files (disk_config, > packages, ...) and exactly two commands (fcopy /etc/network/interfaces and > the > one for setting the root password.) > > The bootloader issue is pretty nasty though, because the 'correct' > configuration is linked very tightly to the installed distribution, your > environment and possibly even the underlying 'hardware'. (Installing a > paravirtualised XenServer instance was a nightmare, because Citrix did not > actually parse the bootloader, but circumvented grub completely instead read > the menu.lst directly and expected to find specifically named boot > configuration. > Took a while to figure that one out...) Yes, this would be one further point in a tips & tricks or extended FAQ section. Maybe one should start with the FAQ and use sections for installation, tips/tricks, trouble shooting, etc. One can even put links there to better places/explanation, but one would have a good starting point in cases of problems/questions/ideas. It's just an idea... ;-) Best regards Dirk -- +--+ | Dr. Dirk Geschke / Plankensteinweg 61/ 85435 Erding| | Telefon: 08122-559448 / Mobil: 0176-96906350 / Fax: 08122-9818106 | | d...@geschke-online.de / d...@lug-erding.de / kont...@lug-erding.de | +--+
Re: FAIBASE/10-misc and hostname
> On Tue, 12 Mar 2013 11:14:31 +0100, Dirk Geschke > said: > I just found some solutions here: > http://wiki.fai-project.org/wiki/Helper_scripts Feel free to use the wiki for all kinds of documentation, hints, tricks,. -- regards Thomas
Re: FAIBASE/10-misc and hostname
Hi Thomas, > FAI major goal was always to be as flexible as possible but also like > to give some structure (the tasks and classes) to the user. I think that is the cause for many initial problems and on the other side it is one of the best features FAI can have. I can do nearly everything with FAI! > Most other installation tools define their essential steps (like > setting language, keyboard layout, disk patitioning,...) and then it's > up to the user to do all optional configuration steps in a self > written postinstall script. This is completely flexible but also with > not structure. > > FAI wants to give more help to the user, by defining some tasks and > providing the use of FAI classes in all parts of the > installation/configuration process. But I never want to make FAI say > "This is the (only) way you have to install you computers". So, it's > not easy to say which steps are essential or which are optional (and > belong to the config space or belong in FAI itself). And therefore > some steps may be in the wrong part of FAI. That had led me to the idea to give some tips and tricks to help people who may have no clue where to start or they need an idea. And of course: A collection of known problems and work-arounds would be nice. Maybe there is alredy one and I did not find it. But some issues like then NFSv4 problems should be easier to find. Especially if the cause for an AUFS crash is caused by this: That is really difficult to identify... Best regards Dirk -- +--+ | Dr. Dirk Geschke / Plankensteinweg 61/ 85435 Erding| | Telefon: 08122-559448 / Mobil: 0176-96906350 / Fax: 08122-9818106 | | d...@geschke-online.de / d...@lug-erding.de / kont...@lug-erding.de | +--+
Re: FAIBASE/10-misc and hostname
Hi Thomas, > > I just found some solutions here: > > > http://wiki.fai-project.org/wiki/Helper_scripts > Feel free to use the wiki for all kinds of documentation, hints, > tricks,. oh, it is open for everyone? I never tried this and was not aware of this... But shouldn't we first agree on where to put all the tips, tricks and hints? Or do you think, this would be the right place? Best regards Dirk -- +--+ | Dr. Dirk Geschke / Plankensteinweg 61/ 85435 Erding| | Telefon: 08122-559448 / Mobil: 0176-96906350 / Fax: 08122-9818106 | | d...@geschke-online.de / d...@lug-erding.de / kont...@lug-erding.de | +--+
Re: FAIBASE/10-misc and hostname
> On Tue, 12 Mar 2013 11:26:45 +0100, Dirk Geschke > said: > And of course: A collection of known problems and work-arounds would > be nice. Maybe there is alredy one and I did not find it. But some > issues like then NFSv4 problems should be easier to find. Especially > if the cause for an AUFS crash is caused by this: That is really > difficult to identify... I would be very happy if you had any idea how to improve this. Maybe use the FAQ on the fai-project.org web page? The sources of the web page are also in git (g...@github.com:faiproject/fai-project.org.git), so feel free to improve this page or use the wiki. -- regards Thomas
Re: FAIBASE/10-misc and hostname
> On Tue, 12 Mar 2013 11:34:37 +0100, Dirk Geschke > said: > But shouldn't we first agree on where to put all the tips, tricks > and hints? Or do you think, this would be the right place? Tips, tricks and hints belong into the wiki. A common problem like the aufs problem belongs to the FAQ. -- regards Thomas
Re: FAIBASE/10-misc and hostname
I find this entire thread to be huge gentlemen. It has everything to do with my nubie status with FAI plus end user community. On 03/12/2013 06:36 AM, Thomas Lange wrote: On Tue, 12 Mar 2013 11:26:45 +0100, Dirk Geschke said: > And of course: A collection of known problems and work-arounds would > be nice. <> so feel free to improve this page or use the wiki. I'd like to suggest MAYBE "more" is not "all better". My reality is that it may take quite a few repeat executions to get the data perfectly correct. As I pursue my personal objectives for FAI, I've been faced with questions like: * Is is safe to re-run fai-setup without re-installing from scratch? Under what circumstances is it required to run fai-setup again? How do I reconcile a statements in existing documentation "Run fai-setup only once" and "after ??? run fai-setup" (exact sources not remembered). * Why does fai-make-nfsroot need a specific choice in kernel version when version spec is not required during fai-setup? These are trivial examples of procedural level questions where design governs the answer. Answers are made difficult by the flexibility that FAI is famous for. I find the "walkthrough" type document to be hugely valuable. Yet I need to underscore the thoughts: 1. Documentation as a whole needs consideration because new users need to know what advise to trust and what advise does not apply in the circumstance. Perhaps a smaller current document collection with a large structured archive of superseded content is useful? 2. FAI is part of a moving target so documents need rev level and date reference because all nubies are not using a single rev at one time. 3. I'm glad that the words "up-to-date" docs was not the focus because covering all the variation is daunting. It's more like a cluster of bees with FAI being the nest. I'm blowing smoke? [I could not resist] I know there is more to the list, but is seems worthwhile to start it. I have seen the wiki to be useful as a framework for documentation because of the built-in concepts -- page content is subject to revision more than replacement (as in publishing a new users manual), and sample file attachments are easy. It has a strong upside for community if it is structured for it. The down side of wiki is the contributor who is off-base technically and the one who presents without concern for the experience level of the reader. When a specific outcome is desired, user experience-to-date is the filter for documentation content. And perhaps the worst downside is apathy. FAI is in no way a plug-n-play application. Sticking with that thought, the value of walk-through and a fool-proof set of example data is golden. The more the merrier? For new users who grew into Linux from other distros it is also tough to bring one environment (?Debian at squeeze rev?) to the table as the platform for FAI. It's my experience that the Ubuntu 3.4.8ubuntu2 version is also not plug-n-play and I'm a little challenged by the quote "...nobody cares about Ubuntu...". As an aside: I also become curious when I find a history where mounting FAI on Fedora [something more like UNIX V5?] becomes hugely frustrating and abandon. Therefore to wrap up all these experiences into one result -- many walk-though sample cases with many platforms contributed by many users as they join the main stream is perhaps the most helpful to the newbie success story. AND it is not all about nubies. Try moving from rev to rev when longevity and heterogeneous environments come into play. Building a homogeneous cluster needs to be one test-case as well as building the next distro [say CentOs follows Debian?] or the next archetecture [say AMD64 follows PowerPC?]. Certainly there are combinations that don't work so where might I find the matrix that exhibits past successes? My desire? -- platform distro, FAI server distro, FAI client distro, archetecture, [others], are all things my math-major friends call "independent variables", and I need to learn about those that work before I experiment with those that are new but better fit my objectives. Sorry to have beaten examples to death. It's more about user community experience than core project authorship. It's also "learn by following"? For my own part I will gladly contribute my success story soon as I find one. I'm hoping FAI permits me to define all(?) hosts on the LAN for the long run instead of piecemeal project for each host and rev. I also hope someday DHCP will permit "build in place" in favor of "build on subnet". If it's any value I might be able to support an on-going test bed to run selected FAI variations against so that FAI might become closer to plug-n-play. Thanks & cheers. Geo
Re: FAIBASE/10-misc and hostname
Hi, George VerDuin wrote on 2013-03-12 14:41:16 -0400 [Re: FAIBASE/10-misc and hostname]: > [...] > It's my experience > that the Ubuntu 3.4.8ubuntu2 version is also not plug-n-play and I'm a > little challenged by the quote "...nobody cares about Ubuntu...". I believe that is a translation error from the German "sich kuemmern um". It's probably supposed to mean "the Ubuntu package is unmaintained" and not "we're not in the least interested what the Ubuntu package looks like". Regards, Holger
Re: FAIBASE/10-misc and hostname
> On Wed, 13 Mar 2013 03:55:53 +0100, Holger Parplies > said: >> little challenged by the quote "...nobody cares about Ubuntu...". > I believe that is a translation error from the German "sich kuemmern um". It's > probably supposed to mean "the Ubuntu package is unmaintained" and not "we're > not in the least interested what the Ubuntu package looks like". Yes, that what I wanted to say. Sorry for the confusion. I would be very happy if anyone would maintain the Ubuntu FAI packages, but I do not have the time to do this. -- regards Thomas
Re: FAIBASE/10-misc and hostname
> On Tue, 12 Mar 2013 14:41:16 -0400, George VerDuin > said: > * Is is safe to re-run fai-setup without re-installing from scratch? Under what circumstances is it required to run > fai-setup again? How do I reconcile a statements in existing documentation "Run fai-setup only once" and "after > ??? run fai-setup" (exact sources not remembered). Normally you run fai-setup once, and after that you run fai-make-nfsroot if you changed something in /etc/fai. > For my own part I will gladly contribute my success story soon > as I find one. That would be very nice. We need more contributions for improving the documentation. -- regards Thomas
Re: FAIBASE/10-misc and hostname
Thanks Thomas. On 03/13/2013 09:36 AM, Thomas Lange wrote: On Tue, 12 Mar 2013 14:41:16 -0400, George VerDuin said: > * Is is safe to re-run fai-setup without re-installing from scratch? Under what circumstances is it required to run > fai-setup again? How do I reconcile a statements in existing documentation "Run fai-setup only once" and "after > ??? run fai-setup" (exact sources not remembered). Normally you run fai-setup once, and after that you run fai-make-nfsroot if you changed something in /etc/fai. Now that I have been engaged in FAI for a short time, your answer makes perfect sense technically. IMO it does presume that the first (only?) fai-setup was successful and a change to /etc/fai was for new user criteria. Further, the answer may not go deep enough when fai-setup aborts. But let's stop that thread and step back to review this transaction as it relates to documentation... Here in the reflector we have gone thru a a partial Q&A exchange. For those of us paying attention to the ebb and flow in mail it satisfies our needs. For those absent from the conversation it presents a google-like challenge to find the same kernel of knowledge, while at the same time the source of the question has not changed. Because the documentation has not changed, the potential of repeating the question remains. Now consider the observation of others that FAI has a steep learning curve. Steep? True or false doesn't matter so much as does presentation. My argument in favor of wiki as a tool centers on this exchange we just had. If I had searched wiki for the exact source of my confusion and I developed a change you agreed satisfied my question, then all who follow us benefit from our work. Less google. Better(?) document set. Work to change happens mostly here on my IP not on your IP. Perhaps not much different from a script change to fai-setup? IMHO the approach describes a win-win. And -- this does not work well for documents published like books... > For my own part I will gladly contribute my success story soon > as I find one. That would be very nice. We need more contributions for improving the documentation. OK, but the untested part of my argument rests with the user community. If a user speaks bash and perl fluently, then fai-setup can be self-documenting and it is unfair to ask for duplicate knowledge in any other published document. In fact, duplication is counter productive, and a negative score from a quality viewpoint. Under these conditions, nubies just need to understand the tools they need to bring to the table. Cheers Geo
Re: FAIBASE/10-misc and hostname
On 03/13/2013 03:39 AM, Thomas Lange wrote: On Wed, 13 Mar 2013 03:55:53 +0100, Holger Parplies said: >> little challenged by the quote "...nobody cares about Ubuntu...". > I believe that is a translation error from the German "sich kuemmern um". It's > probably supposed to mean "the Ubuntu package is unmaintained" and not "we're > not in the least interested what the Ubuntu package looks like". Yes, that what I wanted to say. Sorry for the confusion. Actually less of confusion, more of dumb [dumb can be fixed while stupid is forever]. I approach this from the expectation that if I faithfully follow my predecessors I will have a good outcome. I have not. But I question how faithful I have been. And I can not exactly duplicate the Debioan environment my predesessors trod. So I'm stuck for the moment with Ubuntu that does abort for reasons I don't fully understand. This brings me to viewing the Ubuntu version as lacking quality and the FAI project team of not supporting Ubuntu variation of the project. I do have opinion, I do not criticize. Once I grasp the Ubuntu failure, and maybe have a solution, I will approach Ubuntu as a buggy offering not found in Debian. I would be very happy if anyone would maintain the Ubuntu FAI packages, but I do not have the time to do this. I hope you share my perspective of the difference between support and quality. I doubt FAI is flawed and in need of support, I do suspect some incompatibility caused by differences in packaging between Debian and Ubuntu. Cheers. Geo
Intermediate documentation (was: FAIBASE/10-misc and hostname)
On Mon, 2013-03-11 at 11:17 +0100, Dirk Geschke wrote: > Sounds good, there seems to be a big problem with FAI: The first steps > are very cumbersome and I remember the documentation was not very helpful. > Afterwards, when I got it up and running, I found nearly all in the > documentation... > > It looks like there is a gap between "beginners" and "advanced users". > But I can't say, where it is nor how to fill it... I completely agree with the need for "intermediate" documentation. I still remember my frustration about not getting FAI to work in the beginning. In my view, the problem is that the users of FAI are almost never real beginners. A beginner would use normal Debian installation tools to install Debian. The target audience for FAI has usually significant system management experience and wants (or needs) to do things in specific (possibly non-standard) ways - either out of habit or due to the task at hand. There may be already existing infrastructure in place (DHCP servers, IP numbering and hostname assignment rules, security ramifications) which do not allow a one-to-one following of the examples. Perhaps we need a list of "what if" scenarios with example solutions: - what if there already is a DHCP server present - what if I have no control over that DHCP server - what if I need to use an existing host for NFSROOT, but can not install extra packages on it - what if I need to install a diskless client - what if I install onto exotic hardware not supported by the default kernel - how to manage the config space in a revision control system etc, etc I might contribute some of these, if we agree on a structure where to place these. I also guess that the solutions to some of these already exist, but may need to be better structured / presented. Toomas Tamm
