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
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
|
AIF is the Arch Linux Installation Framework.
License: GPL3. See COPYING.
Authors: Dieter Plaetinck
Patches from Gerhard Brauer, Matthias Dienstbier, Jud Film and 'tuxce'
Quite some code has been taken from the installer project @ http://projects.archlinux.org/?p=installer.git;a=summary
The main authors/contributors of that project are Judd Vinet, Tobias Powalowski, Simo Leone, Aaron Griffin and Dan McGee
Homepage: http://github.com/Dieterbe/aif
** Goals **
The goal of this project is to:
1) provide reasonable clean, DRY, modular and maintainable code for the Arch Linux installer
2) provide complete, easily-reusable libraries for disk partitioning, UI, package management, etc
3) provide some sensible default installation methods (eg interative, automatic (prescripted), ..)
4) allow 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) to:
1) provide 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.
2) be more fancy then needed
** A bit of history **
AIF is based on the old archlinux-installer (/arch/setup), but the code has been madly refactored, reorganized, cleaned
up, improved and in some places replaced.
The initial goal was to build an automated installer with a reusable
backend, but the porting of the userfriendly, interactive installer from /arch/setup quickly became a proof of concept
and even main focus point. See http://www.nabble.com/Fifa:-Flexible-Installer-Framework-for-Arch-linux-td20256427.html
** /arch/setup vs AIF **
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,
nicer date/time setting, auto updating some config files, debug output, logging to a file etc.
* various fixes
- 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.
** Bug/feature request tracking. Getting in touch **
AIF developement happens under the umbrella of the release engineering project of Arch Linux.
- bug tracker: the Arch Linux bugtracker, "Release Engineering" project, category 'AIF'.
http://bugs.archlinux.org/toplevel/proj6
- mailing list: http://www.archlinux.org/mailman/listinfo/arch-releng
There are some known issues (see the bugtracker, TODO file and various TODO's in the source code)
If you encounter issues, please report them on the bugtracker, after checking if they are not reported yet of course.
If you want to get in touch with us, to ask/discuss/.. things, please send to the mailing list.
** Lingo **
- procedure = a 'plugin' for aif that controls how the installation advances and how the interaction with the user happens
- lib = a library for aif with some useful functions (eg lib-pacman handles all pacman related things)
- module = a bundle that can contain zero or more procedures and libraries.
- profile = a fancier name for a config file. some procedures support the use of profiles (eg automatic), others don't (eg interactive)
- partial procedure = a 'mini' procedure that lets the user perform one or more smaller aspects of (or related to) an installation
** Basic workflow **
AIF comes by default with these procedures:
- base: basic, little-interactivity installation with some common defaults.
This procedure is used by the others to inherit from, it is NOT meant to be used directly by end users
- interactive: An interactive installation procedure, modeled after /arch/setup
Asks you some questions, guides you through an installation
and even helps you a bit by updating configuration files on the target
system with your usettings
- automatic: An automated, deploy-tool-alike procedure. designed for low-
to zero interactivity. uses profiles for configuration of the installation/target system.
See /usr/share/aif/examples/ for example profile files.
- partial-configure-network: exposes the network configuration step from the interactive procedure
- partial-disks: Process disk subsystem or do a rollback
- partial-keymap: change your keymap/console font settings. The benefit of this method over a simple loadkeys is that the interactive procedure will
automatically update the rc.conf on the target system with your settings.
You would usually invoke aif like this:
aif -p interactive
aif -p automatic -c <profile file> [-l]
aif -p <custom module name>/<your procedure>
Type `aif -h` or just aif to see more details.
** Packages and file locations: **
The officially supported package is aif, in extra. There are also
unsupported development git packages in AUR. See HOWTO
File locations:
* 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
* logs -> /var/log/aif
** (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:
- You don't need to use the concept of phases, for example the interactive procedure doesn't use them.
- The phases are started by the start_process function. You can also override this function to take flow control in your own hands (like interactive does)
- 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
** Extending AIF **
*** Modules ***
-> Modules are the building blocks in aif
-> user modules are just directories with a 'libs' and 'procedures' subdirectory
where you can put your customized.. guess what. See 'file locations'
-> The core module comes by default and contains everything 99% of the users will need.
Don't name your custom module 'core' (it will be ignored).
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')
*** Procedures ***
-> You can take a procedure, copy it, modify it and call it. that's fine.
-> You can also write a new one from scratch, inheriting some other procedure using
the depend_procedure call and just overriding what you need.
-> 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)
*** Libraries **
-> If you have logic that may be reusable by several procedures, consider
putting the functions in a library so you, and others can easily use it.
*** Profiles ***
-> You can take a profile and modify it
-> you can also use the depend_profile call and just override what you need.
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>'
** 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, 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. (That's the
theory, it isn't always the case like that now, I need to do more refactoring)
|
