Here’s another build of finstall, alpha4. The most important change this time is native support for remote / headless installs via systoold network daemon.
This enables headless installs of FreeBSD in the following fashion:
- Insert the CD with the finstall in the server (obviously, the server needs to have a CD/DVD reader; USB ones are mostly fine). The server can be headless, i.e. without a monitor, a keyboard or a mouse.
- Connect the server to a LAN. No remote-network hops (routing) are allowed since UDP broadcasts are used to locate the headless nodes. Boot off the finstall CD.
- On another machine (one that has monitor+keyboard+mouse or equivalent X11 devices) start the installer front-end.
- In the front-end, opt to connect to a remote finstall node, choose the one you want. At this point you can see boot-time dmesg data from the nodes so you can locate the right one in case there are many of them.
- Proceed to use the front-end GUI just like it was a local install.
- Reboot, configure, use the server, etc.
As described, the primary usage for this is to setup headless servers.
PXE is supported in theory, but not tried. The idea is that, since the whole finstall setup is actually a live FreeBSD system, PXE can be configured manually once the CD is booted somewhere (possibly on a virtual machine), and remote systems can be booted from this CD-based file system, then installed as if they are booted locally. This is experimental and untried.
This mode of installation has many side-effect uses, such as scripting the remote install, etc.
More about this and other features of finstall will be presented on BSDCan 2008.
Update: The original ISO image posted above had a trivial but unfortunate bug. Download the new ISO image with MD5 fingerprint a9eebbdc546565a9eb9c6622bb948d75.
Background: I’m developing something that should eventually become a high performance network server, with high transactions/s rate (basically a database cache). Currently I’m experimenting with various modes of using SMP facilities for the server (thread usage, binding, etc.). A big problem is that, while I temporarily have a server on which to test it, I don’t have a client machine which could push the server to the limits. I currently have a “dumb” multithreaded benchmark client, spawning N threads (N is 40 in these tests), each of which is a blocking network client (i.e. one thread per connection). This setup, when run via local Unix sockets on the server, can achieve 125,000 trans/s, but I believe the result should be much better if the client doesn’t task the CPU of the server.
Marko Zec helped me with that, temporarily providing me a machine which dual boots 7.x and 4.x with his VIMAGE patches, as well as without the patches. Originally I just used the 7.0 system, and achieved something like 62,000 trans/s, which is too low for me. On his insistence I booted 4.11 and ported the client-side benchmark on it. Without any significant modifications except those needed for the difference between gcc 2.9x and gcc 4, the same client code rocketed to 81,000 trans/s! This is using libc_r, meaning the whole 40-threaded thing is visible to the kernel as one process (4.x doesn’t have kernel support for multithreading)! This number is still too low and I’ll probably need to find several machines that could work at the same time to overtax the server (which will be very hard) but just the raw difference between 4.x and 7.x is staggering. Network card is bge, gigabit, directly connected to the server via crossover cable.
On the bright side, VIMAGE patches don’t influence the performance noticeably.
If you’re wondering how long it takes to propagate a commit made on ports to portsnap servers, the answer is: about two hours
I found myself needing to downgrade a system with 8-CURRENT to 7-STABLE. It was almost painless but I’d like to outline the procedure that worked for me:
* Get the right version of the sources with cvsup
* Build the kernel, boot it with reboot -k
* Make buildworld
* Make kernel
* Edit /usr/src/Makefile to add /rescue in front of the PATH so the utilities requiring FBSD_1.1 (hey! what’s with the “cp” utility requiring FBSD_1.1??) don’t get used
* Make installworld
* Mergemaster, etc. as needed
I didn’t have any ports on the machine; If I had I’d rm everything from /usr/local or rebuilt them.
This will probably work less and less reliably as 8-CURRENT diverges from 7-STABLE.
As I’ve mentioned on the @stable mailing list, there’s a new alpha version of finstall available. The changes in this build are:
* ZFS support
* Included bsdstats
* Several bugs fixed
NOTE: This post is about the original Fit-PC, with an AMD GEODE 500 MHz CPU
I got a fit-pc machine the other day The first impressions are not that good:
* While obviously the purchaser was in Europe, I got an American power cable (though the power transformer is luckily universal 110V-220V 50Hz-60Hz)
* There seems to be something loose in the transformer or the cord(s), since apparently it requires jiggling around to make it start. Will probably have to replace it all together.
* Installing Ubuntu with full graphical interface on this machine was a catastrophic waste of resources. The machine a) has only 256 MB of RAM and b) has an extremely slow CPU (500 MHz AMD Geode – this is way slower than what is in EEE PC). It swaps all the time while under GUI.
Suppose you want to use a remote iSCSI device, but you don’t exactly trust either the storage or the network in between. Of course, there’s a way around it
The setup presented here is very simple and will behave like this:
[iSCSI server] -- encrypted data on the server and over the wire -- [iSCSI client]
I’ve got several queries on finstall development, so here’s a few words on the subject. The development has moved to SourceForge.net. The move was made to enable users that don’t have FreeBSD.Org accounts to participate in development. The source code repositories are world-readable. If you’re interested, contact me and I’ll add you to the project as a developer.
One part of the project that will be interesting to many people is the LiveCD ISO-building script, makeimage.py. There’s currently no documentation on it, but its command-line argument are well explained. This script could be useful to people wanting to create their own LiveCD.