I thought I'd just plonk down some notes regarding Arch Hurd, a distribution of the GNU Hurd suite. For those of you who don't know, the Hurd is the GNU project's attempt to replace the UNIX kernel with a series of servers (daemons) working in user-space above the GNU Mach microkernel.
I've managed to install Arch Hurd on a spare computer, thanks mainly to the efforts of maintainer barrucadu, and am going to be taking it for a spin over the next n days/weeks/months.
The Hurd is quite incomplete (it shows when such basic programs as ping fail due to missing protocol support) but already the structure seems to be something special. It boasts such features as multiple UIDs and GIDs per file, translators (allowing programs to handle input/output to files and directories, so that every access to that file/directory triggers that program. It's how the Hurd implements filesystems and mounting, and even allows for more complex but transparent operations as things from CD blocks to FTP and even HTTP content can be boiled down into the same file I/O system local files use)
Installing Arch Hurd at the moment is a somewhat involved process, as there are a few parts of Arch Linux's installer that don't yet work well with the Hurd, or parts of the Hurd that don't work well yet with the installer. Below are a few things I'm going to scribble down for the benefit of myself and possibly anyone actually reading this damned thing.
Please note that I don't really have the faintest clue what I'm doing, though most of the misguided information I'm farting out here comes from vague understanding or misunderstanding of what has been said before by people who do know what they're doing, so pay extreme caution if I recommend that anyone does anything with their system now or any time in the future.
- Visudo doesn't work, claims file is in use. -
EDIT: As of writing (24th of August), a fixed version of sudo is available in the testing repository.
This is due to the Hurd not supporting the file lock system call visudo uses normally, lockf().
Switching visudo to flock(), a different and supported system call, seems to work. In order to do so, use the ABS to pull a copy of visudo from the Arch Hurd repositories, using makepkg -so to save a local copy of the source. Then cd into the source and apply the following change (pulled from a debian-hurd mailing list):
~~~ snip ~~~
diff -r 91d8979bd32f configure.in
--- a/configure.in Thu May 06 19:39:12 2010 +0200
+++ b/configure.in Thu May 06 19:40:22 2010 +0200
@@ -1706,6 +1706,9 @@
;;
*-gnu*)
OSDEFS="${OSDEFS} -D_GNU_SOURCE"
+ # lockf() isn't implemented on the hurd -- use flock instead
+ ac_cv_func_lockf=no
+ ac_cv_func_flock=yes
;;
esac
~~~ snip ~~~
Another thing that might help is to scroll down into the same configure.in file where it mentions LOCKF then FLOCK in that order, and switch them around so the configure file tries to find FLOCK first. I don't know the repercussions of changing the locking call, security or otherwise, except that it made visudo run on my system.
Another change I made on my local copy of sudo was (again in configure.in) to change env_editor to on. (There are probably cleaner ways to do it - in fact, there should be a command line flag to ./configure that does the job - I just failed to get it to work (and happened to be poking in configure.in anyway)) This makes (or should make) visudo respect EDITOR and VISUAL environment variables, which apparently compromises security - but I can't fathom vi, so I like it being there so I can use nano or emacs with visudo.
Then, run autoconf on the configure.in and either ./configure and make (for a local visudo binary) or try going back to the pkgbuild and makepkg -e. (This didn't work when I tried it, though.)
/sbin/adduser: cannot make pipe for command substitution: Address family not supported by protocol
The following as root might help:
touch /servers/socket/1
settrans -fgap /servers/socket/1 /hurd/pflocal
(thanks to barrucadu)
No comments:
Post a Comment