1Warsaw, 1998.07.07 2 3This README shortly describes the features of "oinit" - a very simplistic 4version of init(8) combined with a shell. 5 6Features 7-------- 8 9* oinit is able to run system in multi- and single-user modes, 10* it can be started on system with DEVFS/SLICE (i.e. empty /dev), 11* provides minimalistic user interface, called "shell()", 12* it can run the system startup script (/etc/rc), 13* it can be compiled with -DOINIT_RC to use its own startup script 14 (*very* primitive, but doesn't require any real shell to run it!), 15* doesn't require the whole chain of init->getty->login->shell to be run, 16* it is extremely small, and is ideally suited for situations when 17 there is little memory. 18 19As an additional bonus you receive some obvious and some hidden bugs... :-)) 20This code is at most alpha quality yet. 21 22 23How it works 24------------ 25 26Unlike normal init(8), it forks itself on given number of vty's immediately 27providing shell() interface. Currently it doesn't require (and is unable to 28perform) any authentication, but this is easy to add if needed. 29 30Standard version of FreeBSD kernel looks for /sbin/init first, and then 31tries to execute it. If it fails, it tries to find: 32 /sbin/oinit 33 /sbin/init.bak 34 /stand/sysinstall 35 36So it is easy to make use of it even on standard system - just put it in 37/sbin/oinit and rename /sbin/init to something else, e.g. /sbin/init.bak. 38 39+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 40!!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! 41+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 42Init (or oinit) plays crucial role in the system. If you plan to do any 43changes to your system's init, make sure you have a boot floppy with working 44version of statically compiled init(8) on it - you can very easily put your 45system in unusable state when fiddling with it. 46+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 47 48Shell() interface 49----------------- 50 51It allows you to issue built-in and external commands. Built-in commands 52are listed below. For each command there is short help available, with 53example of usage. 54 55 cd change working directory 56 pwd print working directory 57 set set environment variable (no expansion) 58 unset unset environment variable 59 env print all environment variables 60 echo echo arguments on stdout 61 exit exit from shell (oinit will start a new one after some delay) 62 . source-in a file with commands 63 ? help 64 65Any other command is passed to execvp(3) as it is. 66 67EXCEPTION: if you end the command line with a '&', the command is started 68as daemon. This is NOT the same as in normal shell, where the '&' puts a 69process in background. Here the newly started process is totally dissociated 70from terminal. 71 72Prompt tells you: 73* your `pwd` 74* your PID 75* and that you are root ('#'). 76 77WARNING: this pseudo-shell doesn't do any expansion whatsoever. 78 79To do list 80---------- 81 82- oinit proper: 83 * fix signal handling and transitions, 84 * invent a one-file configuration database (combining as many files 85 from /etc as possible into one) able to properly handle inter- 86 dependencies in running various daemons, 87 * allow for interpreting of such database, and running various 88 programs ourselves (this would eventually allow to make /bin/sh 89 an option, not necessity), 90 * better hooks for incorporating other modules into oinit (see e.g. 91 the telnet() below), 92 * add optional authentication, 93 94- shell(): 95 * more built-ins: perhaps 'kill' and 'ps', 96 * variable expansion, 97 * globbing, 98 * conditionals, 99 * history? (it depends on how much memory it needs). 100 * programmatic hooks for easy customisation of user interface (like 101 hierarchy of commands and contexts), 102 * ... 103 104- implement as a routine (like shell()) a small remote login daemon telnet(), 105 as a built-in module to oinit. It would implement the simplest options of 106 normal telnet, and would itself handle authentication, passing control to 107 shell() on success. The authentication routine would be the same as for 108 checking console access. 109 110And allow me for a moment of day-dreaming: I'd like to rewrite oinit one day 111to be a monolithic one-in-all application, non-forking but multithreaded... It 112would contain all the modules, such as shell(), telnet(), ifconfig() etc... 113started as threads, not separate processes. 114 115Credits 116------- 117 118The overall framework was taken from FreeBSD /sbin/init. 119 120Andrzej Bialecki 121<abial@freebsd.org> 122 123$FreeBSD$ 124