1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
|
AIF is the Arch Linux Installation Framework.
--- Beta software. Use at own risk!! ---
License: GPL3. See COPYING.
Author: Dieter Plaetinck
Homepage: http://github.com/Dieterbe/aif
** --> Intro / Current state of things <-- **
AIF is included on the 2009.02 Arch install CD's as an experimental alternative for the old installer (/arch/setup).
AIF is based on the old installer, but the code has been madly refactored, reorganized, cleaned up and in some places replaced.
AIF comes by default with these procedures:
- interactive: A port of /arch/setup. Should work okay if you don't try too hard to break it ;-)
- quickinst: A port of /arch/quickinst. Work in progress. Don't use this yet.
- automatic: An automated, deploy-tool-alike procedure. Work in progress. Don't use this yet.
AIF may or may not bring much additional value for you when compared with the previous
installer, it depends on what you want to do:
- End users:
On the frontend, the interactive profile is very similar to /arch/setup.
The features are more or less the same, with a few exceptions:
* Different partition/filesystem editor offering more flexibility and options, such as support for LVM and dm_crypt
* Rollback functionality if you change your mind after having formatted filesystems or if something went wrong and you want to retry.
* Some miscellaneous features like the ability to choose between ncurses and CLI mode, debug output, and logging to a file.
- Hackers:
The code base that AIF runs on is very usable for hacking. The code is
modular, reusable and quite complete. If you want to build your own
installation procedures, or want to modify specific aspects of the
out-of-the-box installation procedures, definitely check out how AIF
works. It is built for hacking, reusing code, changing the behaviour in
specific places and making writing custom installers as easy as possible.
Keep in mind that AIF is still in ALPHA phase.
There are some known issues (see the TODO file and various TODO's in the source code)
If you encounter issues, please report them at the Arch Linux bugtracker under the "Release Engineering" project.
( http://bugs.archlinux.org/toplevel/proj6 )
You can also get in touch with the release engineers / aif developers on the arg-releng
mailing list, http://www.archlinux.org/mailman/listinfo/arch-releng
AIF is expected to become the new official installer in the not too distant
future, so go ahead and try it !
** Goals **
The goal of this project is
1) to make the code of the Arch Linux installer more clean, DRY, modular and maintainable.
2) providing complete, easily-reusable libraries for disk partitioning, UI, package management, etc
3) provide some sensible default installation methods (eg interative, quickinst, automatic (prescripted), ..)
4) allowing power users to easily override certain aspects of the installation procedures
or creating customized procedures, leveraging the available code.
The goal of AIF is not (yet):
1) providing an installer who detects your stuff and tries to be smart and configures all your stuff.
If you're interested in this, feel free to build it and I may incorporate it someday.
** File locations (on the install CD): **
* aif.sh -> /sbin/aif
* docs -> /usr/share/aif/docs
* core module -> /usr/lib/aif/core
* user modules -> /usr/lib/aif/user/<module name> (put your own modules here)
* runtime files -> /tmp/aif (package list etc go here)
* logs -> /var/log/aif
A module can have 2 directories: libs, and procedures.
** Procedures **
core/base: basic, little-interactivity installation with some common defaults. You probably don't
want to run this one, although it's useful for other procedures to inherit from.
core/interactive: interactive, reasonably flexible/featured installer (port of /arch/setup)
core/quickinst: mostly DIY. port of /arch/quickinst
core/automatic: automatic installer/deployment tool, can use config files
** Partial Procedures **
These procedures allow you to run a select few functions, in order to reach
a specific goal, usually not installing a system
partial-configure-network.sh Configure network on the runtime system
partial-disks.sh Process disk subsystem or do a rollback
** (Internal) Workflow **
There is a very basic but powerful workflow defined by variables, phases and workers.
Depending on the procedure you choose (or write yourself), these will differ
In the code, they are very recognizable and are named like this:
- variable -> var_<foo>
- phase -> phase_<bar> (an array in which each element is a worker to be executed, with optionally arguments for that worker)
There are 4 phases: preparation, basics, system, finish. (executed in that order)
- worker -> worker_<baz> ( a worker function, called by a phase. implements some specific logic.
eg runtime_packages, prepare_disks, package_list etc)
You can depend on whatever procedure you like (like core/base), to save
yourself some work (you only need to override a few things)
Notes:
- The phases are started by the start_process function. You can also override this function to take flow control in your own hands (eg iterative, menu-based installer)
- you _can_ override _all_ variables and functions in your modules, but you should be able to achieve your goals by
overriding only the 3 basic things and the start_process function, and only in procedures.
- you _must_ specify a procedure, to avoid errors. take 'interactive' if unsure
- don't edit the base procedure (or any other core item), rather make your own. It's easy!
- you're not supposed to define new phases. just override them. logic goes in workers/libariers
Modules are the building blocks in aif. They can contain libraries (for
user interfaces, backend logic, etc) and procedures (how an installation
process should go).
The core module comes by default and contains everything 99% of the users
will need. You can easily make your own modules with in it your own
procedures (and your own libraries, if you need that). If you build your
own libraries, it's generally a good idea to keep
their names in line with what core has (lib-ui.sh, lib-network.sh etc).
Do not put stuff in the core module yourself! If it's good stuff, it might
be merged into core someday... Also, don't name your custom module 'core' (it will be
ignored anyway). Don't call it http either, because you can specify
'http://some/path/to/a/procedure', aif will download that procedure and
execute it (and the module will be 'http')
Note that if you load a module and a library has the same function names as
the core module, it will override the functions from core.
This means you can 'inject' new backend code into core procedures, but you
can also write your own procedures that use your own, or the core libraries.
If you load a module, you actually load it's libraries, not it's procedures!
Procedures are only loaded when needed (because you request them because
of dependencies)
If you need a library from another user contributed module, execute
'depend_module <modulename>' for each module. This way you load all the
libs of that module (not the procedures, use depend_procedure for that.
keep in mind that the position of the depend_procedure statement defines
where your variables/functions might be overridden...)
(very basic dependencies, no version checking etc)
You can specify a core procedure on the command line by specifying
'<procedure_name>', to specify a user contriubuted procedure, specify
'<module_name>/<procedure_name>'
Commandline arguments are parsed by aif.sh but you can extend/override it's
behaviour by overriding $var_OPTS_STRING and the process_vars variable.
Also, you do not _have_ to use the variables they set (eg arg_ui_type). You
usually will set defaults in the configure worker and override with
arguments passed by the user (eg to use cli mode unless user wants dia)
** Contributing **
Install a VM (I use virtualbox-ose, works fine), make a vm, boot the install cd and just follow the HOWTO.
It's probably easiest if you set up your own git clone that you can easily
acces from the VM (You can open a github account and fork my code).
You can edit on the cd itself, but given the low resolution of the VM and the limited
choice of editors, you'll probably edit on your pc, commit, push to github
and pull from the clone on the cd.
If you want to do debugging, just call the debug function and export DEBUG=1
before calling the scripts. (or pass -d)
Keep in mind there are 3 kinds of variables. Those that affect/belong to
the runtime (install cd live environment), target (affects/belongs to the
target installation) and TMP (everything in between or extra). Variablenames
should have _TARGET or _TMP suffixes or none for runtime. (Honestly though,
it isn't always the case like that now, I need to do more refactoring)
Bugs can be reported at http://bugs.archlinux.org/, project "Release Engineering"
Much of the code in the core module is taken (and modified) from the 'real' arch linux install
scripts code. (/arch/setup and /arch/quickinst). the modifications are mostly done
to make the code more (re)useable, to separate backend code, user
interface and flow control (into libraries and procedures) (which was tightly coupled in the original scripts)
and to provide additional features.
I couldn't find what license the code is under, but I assume this
is okay.. if not let me know.
The original code is at
http://projects.archlinux.org/?p=installer.git;a=summary
|
