Talk:Diskless system

From ArchWiki
Revision as of 13:51, 11 January 2013 by Fengchao (talk | contribs) (→‎Client installation: Remove closed discussion)
Jump to navigation Jump to search


I won't add this directly to the article, since Buhman feels so strongly about it, but I'd like to point out that the NVSv4 task on the bug tracker has been re-opened, and it looks like this method for booting NFSv4 may not cover all the bases. Since you have this setup, maybe you could help with testing, Buhman? Giddie (talk) 15:12, 19 December 2012 (UTC)

"has been re-opened"; this was your doing. falconindy is partially non-correct here. sunrpc.ko is a dependency of nfsv4.ko is what's generated with the mkinitcpio.conf in this article. --Buhman (talk) 15:20, 19 December 2012 (UTC)
Yes, I requested it be reopened in the hope that this feature can finally be implemented and supported. I reported the bug in the first place (10 months ago), too. Rather than replying here, could you maybe get involved in the bug, so that the maintainer can actually see what you have to say. Since you're testing this setup, you really need to be talking with falconindy. Giddie (talk) 15:52, 19 December 2012 (UTC)
There's absolutely nothing wrong with the instructions in the article. I have no idea what "supported" means. --Buhman (talk) 16:00, 19 December 2012 (UTC)
"Supported" means maintained by the Arch Linux developers and TUs. It provides certain guarantees of testing and compatibility as the distro moves forward. I trust the Arch Linux developers to do adequate testing and to respond pretty quickly to any bugs that might arise is official packages. I don't think you can offer the same service. Apart from that, if your approach is correct, it simply makes sense that it makes its way upstream, so that future users don't have to make the same manual alterations. Giddie (talk) 16:08, 19 December 2012 (UTC)


If DNSmasq is not appropriate for the job, please write a section explaining why this is the case. Since I use dnsmasq, I'd be interested to know why exactly you think it's not appropriate. What definitely is not appropriate, however, is undoing my edits, for which I've gone to pains to explain my reasoning. Giddie (talk) 10:38, 11 December 2012 (UTC)

No, we don't write sections explaining why sections don't exist. That's just plain stupid. --Buhman (talk) 10:42, 11 December 2012 (UTC)
We write sections explaining why an obvious choice is actually not a good idea, so others can be informed and avoid the same mistake. (Assuming they agree that it is actually a mistake.) Seriously: this wiki is not here to reflect only your own opinions; it's here so that we can all share our knowledge. It's all about collaboration and compromise, and I'm seeing very little of that from you right now. Giddie (talk) 11:34, 11 December 2012 (UTC)
dnsmasq is a problem because it's a little unwieldy primarily due to its crazy amount of scope-creep. What was originally just a dns server got way out of hand. If you say things like listen-address=, that is only applicable for the DNS part, and not, e.g: DHCP. This becomes problematic if say you want your hostapd stuff that also runs isc-dhcp just on wlan0, and then decide you want to PXE boot some stuff off the wired-lan really quick. Nope; have to shut down dhcpd4 to allow dnsmasq to hog all the interfaces and bind wildcard on everything BUT dns. But oh wait, you said port=0? That controls what, just DNS? So DNS is disabled now, and listen-address in this case does absolutely nothing, as well as listen-interface.
It's just a dirty ugly quick "omfg I want dhcp+tftp NAOW" hack, rather than something that should be considered sane to actually systemctl enable. Lots of features, really crappy defaults, and, most importantly, no way to un-configure those defaults (aside from making a fork that would just end up being a less-good isc bind/tftp/dhcp). And compared to bind it's a lousy DNS server anyway. So why it even exists I don't know.
Nothing against you personally; I've, as you can see from the history, reverted dnsmasq edits before. --Buhman (talk) 16:37, 12 December 2012 (UTC)
I'm content enough with the note, so that people can at least inform themselves and make their own decision. So I think we've reached a settlement :) Giddie (talk) 09:47, 13 December 2012 (UTC)

Per-host mountpoints (was: Separate /var)

I feel like treating just /var specially isn't fair. I mean, how would /etc feel? In all seriousness, I think this needs to be reorganized into something like "per-host special mountpoints". --Buhman (talk) 15:30, 12 December 2012 (UTC)

That sounds fine to me, if you want to do that. I'm pretty sure that /var contains everything that makes a host unique (or that's the intention), and I'm keen for people to think about it, since it's an added complication that can easily be overlooked when planning the cluster. Giddie (talk) 15:39, 12 December 2012 (UTC)
As I tried to imply somewhat, I still don't think its a good idea to do *all* of var, maybe a few application-specific subdirectories. For example it's actually desirable in a non-diskless scenario like this to put /var/cache/pacman on a NFS share--effectively working like a local repository mirror. Only in this scenario, we get that for free :D --Buhman (talk) 16:41, 12 December 2012 (UTC)
Yeah, in my setup I share /var/lib/pacman between all clients, and /var/cache/pacman between all clients and the host. Some other directories in /var/cache could probably be safely shared, but my general stance is to opt-in to sharing certain directories in /var for convenience (or storage space), rather than to determine which directories can't safely be shared. I have no problem with providing suggestions for both points of view ("share all of /var except for certain dirs" vs "/var is node-specific except for certain dirs"); it's helpful for readers to have a chance to consider both views and decide what fits their usecase best. Giddie (talk) 09:57, 13 December 2012 (UTC)

how to organize

Heh, we go back to 3+ articles again? :P We're actually agreeing here I think, but I would say "sub-articles" rather than dedicated articles--Buhman (talk) 10:22, 13 December 2012 (UTC)

Well, sub-articles does imply that the tasks are basically the same, which I don't think they are. I think they are very different tasks with different purposes, but which happen to share some configuration. No harm in a page that explains which article deals with what, I suppose. I don't feel too strongly about this, really. This is just what makes sense to me. Giddie (talk) 10:58, 13 December 2012 (UTC)
What would be really cool is if the reading went something like: the user reads about each of the ways that this could be done, then selects what he wants to see (whatever combinations), and then gets a tailored-to-order article with just the stuff he's interested in. --Buhman (talk) 10:16, 13 December 2012 (UTC)
I don't think that will be possible on this MediaWiki setup without the kind of duplication we're keen to avoid. Probably best to split out the common stuff into separate articles, and link from an article for each usecase. Giddie (talk) 10:19, 13 December 2012 (UTC)
Here is another idea: Instead of one index page for just Network Installation Guide and PXE, we can add a index page about all of the different installation methods in Category:Getting and installing Arch. There are 49 articles in the category, so a good index page can make them stay organized. -- Fengchao (talk) 13:14, 13 December 2012 (UTC)
This sounds like a good idea to me. Giddie (talk) 14:42, 13 December 2012 (UTC)

Per-client hostnames

I've been meaning to ask; how exactly did you manage to make each client's hostname unique? --Buhman (talk) 18:09, 19 December 2012 (UTC)

In my cluster, hostnames are assigned along with IPs by the DHCP server, according to the MAC address. Giddie (talk) 18:17, 19 December 2012 (UTC)
Could you be bothered to add this to the article? Surely there's some client-side magic required because the dhcp lease happens in early-boot and the hostname isn't set until after switch_root --Buhman (talk) 20:09, 19 December 2012 (UTC)
The truth is there's no trick. The hostname gets set in early boot, and if there's no /etc/hostname, it doesn't seem to get changed. I was worried that would stop working with systemd, but it's still the case. (I have issues with /var, though. I might need to mount it in initcpio.) Giddie (talk) 23:12, 19 December 2012 (UTC)

Bootstrapping installation

The mkarchroot command as listed doesn't work with current devtools: it errors "illegal option -- -". I assume it gets confused by the '--arch' option, because leaving that out allows it to continue. Isn't mkarchroot supposed to pass unrecognized options on to pacman? Ackalker (talk) 16:52, 28 December 2012 (UTC)