Installing OS Inferno New Edition
OUTDATED: This article is outdated; for installation under modern OS, see the new article .
Update: Added description of the installation under Windows XP SP2 .
Update: Added installation description for Mac OS X 10.4.8 Tiger .
Update: Added installation description for Mac OS X 10.5.5 Leopard .
Yes, the version in svn calls itself that way! Install, run the browser (Charon) and see for yourself. (In principle, the latest release is " Fourth Edition ", but in practice it has long been the same svn - "Fourth Edition" was released around 2004, and now on the offsite site under the guise of "Fourth Edition" svn snapshot from 20071003 is posted.)
')
The svn version is absolutely stable, and, unlike the Fourth Edition install, it is much easier to update. It is no less convenient for installation on combat servers or release of your application. In general, the only drawback is the need to have a subversion and a compiler for building the system, everything else is a plus.
So, we put the fresh OS Inferno from SVN, in hosted mode (i.e., in the form of an emulator running under another OS).
Although Inferno should be installed and work the same on all systems, we all know perfectly well that there are always nuances. I tested the installation on Hardened Gentoo Linux and on Ubuntu 8.04. I hope this choice of systems will override most of the nuances of installation in other Linux distributions.
Gentoo will have no problems with the compiler and .h files, I assure you. :) But Hardened will add some work. The fact is that
That's what's not here ... uh ... there is nothing here. :) No Hardened, no subversion, no libraries, no .h files. We'll have to put:
Perhaps you will need to connect additional repositories, I will not say for sure - I already had them connected to install other applications.
The following is the installation from root, to the
The time / traffic / disk space costs are approximately as follows:
We swing. All commands, unless otherwise stated, are executed as root. When installing to your home directory, install INFERNO_ROOT, for example,
Customize compilation options. Instead of
Putting the system. Remember,
Configure emu options. It is advisable to register this command in
Configure user inferno. When installing to the home directory, these commands do not need to be executed. The second chown is needed when the TPE is on.
Update: see the comment on the / tmp configuration .
In principle, at this point OS Inferno is installed, and it can be used. But “Fourth Edition” includes additional fonts (B & H Lucida), which, due to licensing restrictions, Google does not allow spreading to svn on code.google.com. In principle, most applications will work without them. In addition, they can be replaced with alternative free fonts (they seem to have done so in the Acme SAC project). But I did not understand this. Therefore, we now, quickly, extort and install in the temporary directory "Fourth Edition", and extract from it these fonts. :)
The semicolon at the beginning of the lines is the invitation to Inferno sh. Finishing work with Inferno - in text mode either Ctrl-D or Ctrl-C, in graphic mode - closing of the Inferno graphic window. (The graphical environment is started with the
Log in as user inferno. When installing in your home directory, skip this step.
Login as a regular user. The
When you start
When installing to the home directory, this setting ends - there is no point in setting up three authorization entities with a bunch of passwords when working under a single account.
First you need to explain what is being configured and why. Authorization works as follows: the client and the service mutually authenticate each other using certificates based on private / public keys - everything is almost like that of ssh or https. Almost because they authorize each other really mutually . To do this, both of them must obtain their certificates from the same CA (certificate authority), which both trust. So, it is the CA, by issuing or not issuing these certificates, determines whether the client will have access to the service or not.
Thus, we need to configure three different systems - an authorization server, a useful service, and a client terminal. To do this, we can run three independent
First of all, you need to register the address (hostname or IP) of the authorization server on the client and service machines. But, since the files they have in our configuration are the same, it is enough to edit one file / usr / local / inferno / lib / ndb / local (you can enter 127.0.0.1):
Next, run the authorization server. It will run under the user inferno, and all files with keys and CA certificates will be available only to this user.
... clear the key database
... we generate the certificate of our CA, on the specified name (any)
... we start the authorization service, and you will need to set a password, which you will need to enter in the future each time you start this service - this is necessary because keys in files will be encrypted with this password
... now we can have real user accounts with passwords on our authorization service, finally :) - one for the user inferno (just to avoid having a third user, they will use the second server to start useful services) and the second for the user powerman (which will use the client terminal on the third server to connect to the useful service on the second server)
... well, and admire the TCP services running on this "server"
We leave the authorization server to work, and run the next
... ndb / cs is something like a universal resolver, without it you don’t work with the network in Inferno (there are ndb / dns, but you can not start it in hosted mode and use the host OS dns-resolver)
... we turn to the authorization service (the first server), log in with our username / password, and receive our certificate from it (this is a one-time operation, provided that the certificate is not expired and the file where the received certificate will not be deleted now will be deleted).
... now, having a certificate, you can start a useful service - for example, rstyx, which allows you to remotely execute commands on this server - an analog of ssh
We leave it to work and run the third
... now we can connect to the second server and execute a command on it. for example, let's see the list of processes first on this terminal, and then on the second server
Here everything is absolutely trivial:
RTFM. RTFM. And again RTFM. The system is very different from the traditional. And do not count on reading the documentation - you need to read the source code, the most important thing is there. :)
When there is an understanding of how it works - write to Limbo. (I do not advise writing sh - it is too slow, which is rather strange, by the way.) Write network services, distributed systems, or full-fledged GUI applications.
Good luck! :)
Update: Added description of the installation under Windows XP SP2 .
Update: Added installation description for Mac OS X 10.4.8 Tiger .
Update: Added installation description for Mac OS X 10.5.5 Leopard .
New edition
Yes, the version in svn calls itself that way! Install, run the browser (Charon) and see for yourself. (In principle, the latest release is " Fourth Edition ", but in practice it has long been the same svn - "Fourth Edition" was released around 2004, and now on the offsite site under the guise of "Fourth Edition" svn snapshot from 20071003 is posted.)
')
The svn version is absolutely stable, and, unlike the Fourth Edition install, it is much easier to update. It is no less convenient for installation on combat servers or release of your application. In general, the only drawback is the need to have a subversion and a compiler for building the system, everything else is a plus.
So, we put the fresh OS Inferno from SVN, in hosted mode (i.e., in the form of an emulator running under another OS).
Installation features in different systems
Although Inferno should be installed and work the same on all systems, we all know perfectly well that there are always nuances. I tested the installation on Hardened Gentoo Linux and on Ubuntu 8.04. I hope this choice of systems will override most of the nuances of installation in other Linux distributions.
Hardened gentoo linux
Gentoo will have no problems with the compiler and .h files, I assure you. :) But Hardened will add some work. The fact is that
emu can work both in the interpretation mode of the Dis virtual machine bytecode and in the JIT mode. And Hardened (more precisely, PaX entering into it) very much does not like code generation on the fly with transfer of control to it. Therefore, to run emu in JIT mode, you will need to partially disable PaX. This is done by the paxctl and chpax . On systems without PaX, these commands are most likely not, and they do not need to be executed. Another nuance occurs when Trusted Path Execution (TPE) is enabled, but it is usually sufficient to ensure that the rights to the emu directory belong to root. How to deal with SeLinux - understand yourself. :)Ubuntu 8.04
That's what's not here ... uh ... there is nothing here. :) No Hardened, no subversion, no libraries, no .h files. We'll have to put:
apt-get install subversion build-essential apt-get install libx11-dev libxext-dev x11proto-xext-dev
Perhaps you will need to connect additional repositories, I will not say for sure - I already had them connected to install other applications.
Install OS Inferno
The following is the installation from root, to the
/usr/local/inferno directory, in full multi-user mode . Differences when installing from a regular user in ~/inferno/ I will mention in the course of the process - basically they boil down to the fact that some commands are meaningless to execute and / or not necessary.The time / traffic / disk space costs are approximately as follows:
- archive version of svn takes about 30 MB , but it is clear that svn will pump traffic much more
- the system is completely [re] going to my Core2Duo 6600 in about two minutes
- in the installed form on the disk, it takes about 250 MB
We swing. All commands, unless otherwise stated, are executed as root. When installing to your home directory, install INFERNO_ROOT, for example,
/home/powerman/inferno . And, of course, follow all the commands from a regular user.export INFERNO_ROOT = / usr / local / inferno svn checkout http://inferno-os.googlecode.com/svn/trunk/ $ INFERNO_ROOT cd $ INFERNO_ROOT
Customize compilation options. Instead of
perl -i -pe you can run your favorite text editor and edit mkconfig pens. export PATH = $ INFERNO_ROOT / Linux / 386 / bin: $ PATH
perl -i -pe 's / ^ ROOT =. * / ROOT = $ ENV {INFERNO_ROOT} / m' mkconfig
perl -i -pe 's / ^ SYSHOST =. * / SYSHOST = Linux / m' mkconfig
perl -i -pe 's / ^ OBJTYPE =. * / OBJTYPE = 386 / m' mkconfig
Putting the system. Remember,
paxctl needed only on systems protected by PaX and only to run in JIT mode.sh makemk.sh mk nuke mk install paxctl -psmxe linux / 386 / bin / emu
Configure emu options. It is advisable to register this command in
~/.bashrc - in order not to pass these parameters every time emu start emu . (By the way, it is also very desirable to set export PATH=/usr/local/inferno/Linux/386/bin:$PATH in ~/.bashrc export PATH=/usr/local/inferno/Linux/386/bin:$PATH - it will be more convenient to run emu and limbo .) Of course, you need to set the size of the Inferno window system not necessarily 1024x768. In principle, it is more convenient when the size of the Inferno window is less than the resolution of the host OS. The -c0 disables JIT (to enable, simply run emu -c1 ). The fact is that with JIT enabled, it is harder to debug your applications - the debugger does not work, the borders of arrays are less controlled, etc. And the speed of Inferno and without JIT is more than impressive.export EMU = "- r $ INFERNO_ROOT -g1024x768 -c0"
Configure user inferno. When installing to the home directory, these commands do not need to be executed. The second chown is needed when the TPE is on.
groupadd inferno useradd -m -s / bin / bash -g inferno inferno chown -R inferno: inferno $ INFERNO_ROOT chown -R root: root $ INFERNO_ROOT / Linux / 386 / bin / echo exec $ INFERNO_ROOT / Linux / 386 / bin / emu $ EMU >> ~ inferno / .bashrc mv usr usr.skel ln -s / home usr cp -a usr.skel / inferno / * ~ inferno /
Update: see the comment on the / tmp configuration .
Fonts
In principle, at this point OS Inferno is installed, and it can be used. But “Fourth Edition” includes additional fonts (B & H Lucida), which, due to licensing restrictions, Google does not allow spreading to svn on code.google.com. In principle, most applications will work without them. In addition, they can be replaced with alternative free fonts (they seem to have done so in the Acme SAC project). But I did not understand this. Therefore, we now, quickly, extort and install in the temporary directory "Fourth Edition", and extract from it these fonts. :)
mkdir / tmp / inferno
cd / tmp / inferno
wget http://www.vitanuova.com/dist/4e/20071003/inferno.tgz
wget http://www.vitanuova.com/dist/4e/20071003/Linux.tgz
tar xzf inferno.tgz
tar xzf linux.tgz
chown -R root: root / tmp / inferno
chpax -psmxe Linux / 386 / bin / emu
sh install / Linux-386.sh / tmp / inferno /
cp -r fonts / {lucida, lucidasans, lucm, pelm, licence} / usr / local / inferno / fonts /
rm -rf / tmp / inferno
We are testing
The semicolon at the beginning of the lines is the invitation to Inferno sh. Finishing work with Inferno - in text mode either Ctrl-D or Ctrl-C, in graphic mode - closing of the Inferno graphic window. (The graphical environment is started with the
wm/wm command.)Log in as user inferno. When installing in your home directory, skip this step.
# su - inferno ; cd ; pwd / usr / inferno ; cat / dev / user inferno
Login as a regular user. The
cp command initializes your home directory; you do not need to repeat it in the future before launching Inferno. The installation of PATH and EMU is also better to register in ~/.bashrc . Then to run Inferno it will be enough to run emu .$ cp -r /usr/local/inferno/usr.skel/inferno/* ~ / $ export PATH = / usr / local / inferno / Linux / 386 / bin: $ PATH $ export EMU = "- r / usr / local / inferno / -g1024x768 -c0" $ emu ; cd ; pwd / usr / powerman ; cat / dev / user powerman
Initial setting Inferno
When you start
emu system is minimally initialized, and then sh run, which executes /lib/sh/profile to further initialize the system. I usually write to it:- Setting the time zone. In principle, this can be done once by copying the file, but using
bindis more than Infern-ish. :) - Change to the home directory of the current user (by default, the system is in the root directory).
- If the appropriate files are configured in the user's home directory, continue the system initialization with these files.
bind / locale / Moscow / locale / timezone
cd
load std
and {ftest -e namespace} {nsbuild}
and {ftest -e profile} {run profile}
When installing to the home directory, this setting ends - there is no point in setting up three authorization entities with a bunch of passwords when working under a single account.
Configure authorization
First you need to explain what is being configured and why. Authorization works as follows: the client and the service mutually authenticate each other using certificates based on private / public keys - everything is almost like that of ssh or https. Almost because they authorize each other really mutually . To do this, both of them must obtain their certificates from the same CA (certificate authority), which both trust. So, it is the CA, by issuing or not issuing these certificates, determines whether the client will have access to the service or not.
Thus, we need to configure three different systems - an authorization server, a useful service, and a client terminal. To do this, we can run three independent
emu on our machine - from the point of view of Inferno, these will be three different servers on which different applications will run. Of course, with this option there are some limitations - for example, it is impossible to start two identical network services in different emu - they will have a conflict when trying to open a TCP port. Well, the files on the disk are shared, of course - but this does not apply to “virtual” files (a la / proc and / dev in Linux), which are used very actively in Inferno. So the differences between these three emu is enough for you to perceive them as really different and independent servers.First of all, you need to register the address (hostname or IP) of the authorization server on the client and service machines. But, since the files they have in our configuration are the same, it is enough to edit one file / usr / local / inferno / lib / ndb / local (you can enter 127.0.0.1):
SIGNER = powerman.name
Next, run the authorization server. It will run under the user inferno, and all files with keys and CA certificates will be available only to this user.
# su - inferno ; cat / dev / user; echo inferno
... clear the key database
; cp / dev / null / keydb / keys; chmod 600 / keydb / keys
... we generate the certificate of our CA, on the specified name (any)
; auth / createsignerkey powerman.name
... we start the authorization service, and you will need to set a password, which you will need to enter in the future each time you start this service - this is necessary because keys in files will be encrypted with this password
; svc / auth Key: Confirm key:
... now we can have real user accounts with passwords on our authorization service, finally :) - one for the user inferno (just to avoid having a third user, they will use the second server to start useful services) and the second for the user powerman (which will use the client terminal on the third server to connect to the useful service on the second server)
; auth / changelogin inferno new account secret: confirm: expires [DDMMYYYY / permanent, return = 23102009]: permanent change written ; auth / changelogin powerman new account secret: confirm: expires [DDMMYYYY / permanent, return = 23102009]: permanent change written
... well, and admire the TCP services running on this "server"
; netstat tcp / 0 inferno Announced 0.0.0.0! 6673 ::! 0 tcp / 1 inferno Announced 0.0.0.0! 6677 ::! 0 tcp / 2 inferno Announced 0.0.0.0! 6671 ::! 0 tcp / 3 inferno Announced 0.0.0.0! 6672 ::! 0 ;
We leave the authorization server to work, and run the next
emu - with a useful service.# su - inferno ; cat / dev / user; echo inferno
... ndb / cs is something like a universal resolver, without it you don’t work with the network in Inferno (there are ndb / dns, but you can not start it in hosted mode and use the host OS dns-resolver)
; ndb / cs
... we turn to the authorization service (the first server), log in with our username / password, and receive our certificate from it (this is a one-time operation, provided that the certificate is not expired and the file where the received certificate will not be deleted now will be deleted).
; getauthinfo default use signer [$ SIGNER]: remote user name [inferno]: password: save in file [yes]:
... now, having a certificate, you can start a useful service - for example, rstyx, which allows you to remotely execute commands on this server - an analog of ssh
; svc / rstyx ; netstat tcp / 0 inferno Announced 0.0.0.0! 6668 ::! 0 ;
We leave it to work and run the third
emu - terminal user powerman.$ emu ; cat / dev / user; echo powerman ; ndb / cs ; getauthinfo default use signer [$ SIGNER]: remote user name [powerman]: password: save in file [yes]:
... now we can connect to the second server and execute a command on it. for example, let's see the list of processes first on this terminal, and then on the second server
; ps
1 1 powerman 0: 00.0 release 74K Sh [$ Sys]
8 7 powerman 0: 00.0 alt 17K Cs
11 1 powerman 0: 00.0 ready 74K Ps [$ Sys]
; cpu powerman.name ps
1 1 inferno 0: 00.0 release 83K Bufio [$ Sys]
8 7 inferno 0: 00.0 alt 17K Cs
13 1 inferno 0: 00.0 alt 9K Listen
15 1 inferno 0: 00.0 release 9K Listen [$ Sys]
22 1 powerman 0: 00.0 ready 1K Ps [$ Sys]
;
System update
Here everything is absolutely trivial:
cd / usr / local / inferno svn up mk install
What's next?
RTFM. RTFM. And again RTFM. The system is very different from the traditional. And do not count on reading the documentation - you need to read the source code, the most important thing is there. :)
When there is an understanding of how it works - write to Limbo. (I do not advise writing sh - it is too slow, which is rather strange, by the way.) Write network services, distributed systems, or full-fledged GUI applications.
Good luck! :)
Source: https://habr.com/ru/post/42998/
All Articles