HI folks,

I have followed this guide, http://debianaddict.com/2012/06/19/d...hcppxenfstftp/, but I would like to use SMB instead of NFS.

My setup is Ubuntu 14.04 LTS, running the Zentyal stack that is offering Debian Jessie on the network.

I have took guidance from this, https://www.plop.at/en/ploplinux/liv...ux.html#pxel31, however SMB does not work. I don't know what the root argument should be, as the guide I followed uses root=dev/nfs, do I need to recompile the kernel to boot over SMB?

If you want to do diskless booting with SMB, you will need to do some serious customization. You won't need to recompile the kernel, I don't think, but you will have to customize the initrd with your own customized root mounting method and you will have to radically rethink where the root will "actually" be.

See, SMB does not directly offer the sort of file system permissions required to run linux. So, you could do something like:

1) Serve up a LiveCD style squashfs image by SMB, which is then combined with aufs with local tmpfs to run like a LiveCD. If you don't already understand every term I just mentioned...probably don't try this.

2) Serve up a tar.gz archive file via SMB, which is then extracted in its entirety into a local tmpfs to run like a normal local "hard drive" setup, just with the entire OS stored in RAM. This will work okay if you have at least 3GB of RAM. This is based on my "RAMBOOT" how-to, although I do it with a local hard drive or USB drive.

3) Do something more sophisticated which combines some directories mounted via SMB - use trial and error to figure out which ones will work (this will probably introduce weird bugs and security holes), but with a root that is extracted from a tar file or squashfs/aufs/tmpfs.

Trying to directly run on an SMB mount will just not work, though.

If you haven't really done PXE diskless booting before, I would really strongly suggest you use nfs first, even if you just want to use it as a learning experience to do something without nfs.

1 members found this post helpful.

Thank you for a very detailed reply, is there anything else I can use? Read only is okay as I can chroot into it to run any lasting commands on the host machine itself I can always have r/w access to write anything back on the machine via SMB.

The purpose for this is to use it for rescue, data recovery and creating images. I don't like not being able to log in these instances, for example if it won't boot, I can look at the logs of whatever is serving the instance and remedy where necessary. I cannot log with NFS and it seems to be insecure.

I've seen CIFS thrown about, would that work? Can I log and secure it? SambaFS? Can it all be done with tftp?

I would suggest that you either use nfs or you get used to booting off a USB drive for such tasks. I don't see any practical way to encrypt sending OS files over the network without a USB drive containing an encryption key anyway, so you might as well boot from it.

The GNU/Linux OS really expects *nix style file permissions based on userid/groupid/etc, and there are various special file permissions required for various special file types used by the OS. As far as I'm aware, nfs is the only network file system which supports this natively. (Although various protocols which allow remote access of devices as if they were local may be close enough to native - such as nbd, iSCSI, and so on.)

I don't need to encrypt sending files, I just want the shares to be password protected!

There must be a way, this is Linux after all.

I'm going to try LTSP, see if I can get that to work the way I want it to.

LTSP uses nfs.

I would look at kerberos security on nfs before trying to mess around with SMB with password protection.

Anyway, if you really want to use SMB then I would suggest a radical rethink about what exactly the boot process will be. Like I said, root on an SMB mount simply won't work. But you can use an SMB share to serve up a tar file that you extract to a file system that root CAN accept, such as tmpfs. The target computer is going to need a decent amount of RAM for this, but like I said it will work with 3GB or RAM. Obviously, you'll need to customize the initrd to take in password input, but of course that can be spoofed at the tftp level since the tftp file is sent unencrypted and unprotected. The bottom line is that if you don't entirely trust your LAN, you can't really trust that the PXE booted machine hasn't loaded up a trojan which records the password you type in.

According to everything I've been reading, it uses sshfs/nbd.

I trust my LAN, I just want to keep data secure. I am using the Zentyal stack, but that still misses out that I _cannot_ log nfs access if I go that route.

I just want it to boot over SMB. I forgot to mention I intend to have two shares, one to boot, the other to store data / images in. This one will be protected.

Ah, I see that my knowledge is out of date. Originally, it was nfs only. I see that now LTSPWithoutNFS uses squashfs/nbd/unionfs/tmpfs in a liveCD style rather than nfs (although nfs remains an option).
Then just use the original Debian page you referenced. It exports nfs read only, so there's no way to overwrite it. It uses aufs/tmpfs to provide read-write capability only to local RAM.
What is the problem, precisely? You seemed to care about logging only so you could try and troubleshoot what went wrong when something goes wrong. But, trying to customize your own solution in a way that's radically different from what others are doing is going to make it far more difficult to figure out how to fix it.
You can use any file system you want for data storage. Just put whatever you want for them in /etc/fstab. But the root partition has various requirements that SMB simply does not fulfill.

But you can indirectly use SMB to serve up a squashfs image file, which then can be used as part of an aufs (or unionfs) merge with a tmpfs ramdisk. Thing is, these are all complicated to set up. So I would very highly recommend you first start with something simpler - something which others have already written guides for - before trying to modify it into something with SMB somehow shoehorned in there.

I like to log, I want to know what's going on. This is my number one reason why I want to use SMB. If there is another way to verbose log NFS access, then I'll do that instead

To be honest, I have never enabled logging in nfs, so I don't know what to expect from it. A quick google suggests that "nfswatch" may do what you want. Here's a link to the Ubuntu man page:

http://manpages.ubuntu.com/manpages/...fswatch.8.html

I'll give that a go. Somehow, LTSP killed the DHCP server Zentyal uses so I need to reinstall.

Unlike this forum, the Zentyal one is next to useless.

Thank you for your help, IsaacKuo

You're welcome, and thanks! Let us know how it goes. And since I just recently set up a kind of bizarre diskless netbooting setup myself, my experience is fresh in my mind so I can help with specifics.

I have a tftp/dhcp/nfs server that is, itself network booting off of another nfs/dhcp server (but without tftp). Confusing? Yes. Did I learn a lot of weird gotchas along the way? You bet!

1 members found this post helpful.

[delete duplicate]