From Fedora Project Wiki
No edit summary
(review doc)
 
(6 intermediate revisions by 3 users not shown)
Line 4: Line 4:
= Source Overview =
= Source Overview =


anaconda has a lot of source, and this can be a little intimidating at first.  It can be difficult to figure out where to even start looking when you're trying to track a problem down.  This guide is meant as a very high level overview of the various groups of source files and what sorts of things they cover.  It's not incredibly detailed, and some source files don't want to fit into categories.  Lots of pieces of functionality are spread out across multiple files.
anaconda has a lot of sources, and this can be a little intimidating at first.  It can be difficult to figure out where to even start looking when you're trying to track a problem down.  This guide is meant as a very high-level overview of the various groups of source files and what sorts of things they cover.  It's not incredibly detailed, and some source files don't want to fit into categories.  Lots of pieces of functionality are spread out across multiple files.  The main article about [[Anaconda]] describes where to obtain the source code, which is presently maintained in a 'git' repository.


== Interface ==
== Interface ==
pyanaconda/cmdline.py<BR>
* pyanaconda/ui/gui/
pyanaconda/gui.py<BR>
* pyanaconda/ui/tui/
pyanaconda/installinterfacebase.py<br>
pyanaconda/text.py


These files handle the user interfaces.  There are three interfaces supported by anaconda:  graphical, text, and the command line mode.  Each is implemented by its own python file that contains classes for drawing various types of windows and so forth.
These are the primary UI files for the interfaces supported by anaconda:  graphical, text, and command line (which is really just a special form of text).  Each is implemented by its own directory.  For the graphical installer, the glade interface files are in the same location.  For the text installer, this also includes the code required to do line-oriented input/output.  There is a well-defined API here allowing for both adding additional interfaces and extending the existing interfaces with new screens.


data/ui<br>
* pyanaconda/ui/__init__.py
pyanaconda/iw/<BR>
* pyanaconda/ui/common.py
pyanaconda/textw/
* pyanaconda/ui/communication.py
* pyanaconda/ui/lib/


The pyanaconda/iw/ directory contains python files for the graphical interface screens.  The pyanaconda/textw/ directory contains python files for the text interface screensThe data/ui/ directory contains glade interface description files that are also needed for graphical mode. In general, we are trying to remove as much of text mode as possible and move everything in the graphical interface to using glade.
These files and directories contain code common to all supported interfaces.  The first two files contain mostly base classes with code common to both the GUI and TUIcommunication.py is a small file containing constants and methods for communicating between objects within the UI.


pyanaconda/dispatch.py
* pyanaconda/vnc.py


The dispatcher is a state machine that controls moving between steps in the installer.  It knows which screen to go to when a Next or Back button is clicked, and knows which steps should be skipped depending on a variety of settings.  Each mode of installation provides its own set of steps that should be skipped or added back in.  Install classes (covered later) may also specify steps to skip or addIn addition, various other machine-specific details anaconda discovers and user selections can alter the set of steps.
This file controls setting up VNC for when it is requested during installation.  Afterward, installs proceed in graphical mode.


pyanaconda/vnc.py
== Custom Widgets ==
The anaconda GUI makes use of some custom widgets.  Everything listed below either implements these widgets or is needed for support.


This file controls setting up VNC for when it is requested during installation.  Afterwards, installs proceed in graphical mode.
* widgets/data/


== Partitioning ==
This directory contains images used by the timezone map widget.
pyanaconda/storage/dasd.py<br>
pyanaconda/storage/devicelibs/<br>
pyanaconda/storage/fcoe.py<br>
pyanaconda/storage/iscsi.py<br>
pyanaconda/storage/zfcp.py


These files handle probing, configuring, starting, and stopping the advanced storage systems that anaconda supports.  This includes both hardware devices (FCOE, iSCSI, RAID, ZFCP, etc.) and software abstractions (encryption, lvm, etc.)  LVM and RAID are heavily used while the others are much less common.
* widgets/glade/
* widgets/python/


pyanaconda/storage/formats/
These two directories are support files.  The glade subdirectory contains code to help glade understand these new widgets so they can be used in the interface builder.  The python subdirectory contains code to allow using the widgets through gobject-introspection in a more native Python manner.


These files handle writing some sort of filesystem or filesystem-like abstraction to a storage device.  Think of this as a layer on top of something in pyanaconda/storage/devicelibs/.  Filesystem-like abstractions include disk labels, encryption, machine-specific boot partitions, and swap.
* widgets/src


pyanaconda/partIntfHelpers.py
And then this is the code that implements the widgets themselves.  There is one header and one source code file per widget class.


This file contains methods that are used for error checking, input validation, and displaying error messages.  The graphical and text interfaces make use of it.
== Partitioning ==
 
All partitioning code is now contained in the python-blivet package, which we also work on.
pyanaconda/storage/__init__.py<br>
pyanaconda/storage/errors.py<br>
pyanaconda/storage/miscutils.py<br>
pyanaconda/storage/size.py<br>
pyanaconda/storage/storage_log.py<br>
pyanaconda/storage/udev.py
 
These files form a support library within the storage module, taking care of a variety of small tasks that don't fit well in another group.  For the most part, the names describe what they do.  pyanaconda/storage/__init__.py handles a rather large number of catch-all tasks including reading and writing storage-related configuration files, probing for existing installations, coordinating storage actions, marshalling data between storage objects, and performing sanity checks.
 
pyanaconda/storage/deviceaction.py<br>
pyanaconda/storage/devices.py<br>
pyanaconda/storage/devicetree.py<br>
pyanaconda/storage/partitioning.py<br>
pyanaconda/storage/partspec.py
 
This group of files implements the partitioning logic.  It holds the DeviceTree abstraction that stores existing partitions and requests in a meaningful way, defines the actions needed to write storage requests to disk, handles automatic partitioning (which is the default), and knows how to grow and shrink all requests until they fit in the space provided.  Partitions themselves are created on disk by using the pyparted package.


== Bootloader ==
== Bootloader ==
pyanaconda/bootloader.py<br>
* pyanaconda/bootloader.py
pyanaconda/booty/


These files control writing out the bootloader to the installed system.  Each type of machine has its own bootloader quirks, and therefore has its own file in the booty/ modulebootloader.py ties it all together.  This is useful both for fresh installations as well as upgrades.
This file controls configuring and writing out the bootloader to the installed system.  Each type of machine has its own bootloader quirks (what types of devices and filesystems are supported by the bootloader, the syntax of the config file, etc). and therefore has its own classThis file additionally handles pulling together kernel command line arguments.


== Configuration ==
== Configuration ==
pyanaconda/desktop.py<BR>
* pyanaconda/desktop.py
pyanaconda/firewall.py<BR>
* pyanaconda/keyboard.py
pyanaconda/language.py<BR>
* pyanaconda/localization.py
pyanaconda/network.py<BR>
* pyanaconda/network.py
pyanaconda/security.py<BR>
* pyanaconda/ntp.py
pyanaconda/timezone.py<BR>
* pyanaconda/timezone.py
pyanaconda/users.py
* pyanaconda/users.py


These files hold the configuration settings that are either entered through the interface or through kickstart.  To some extent they affect the installation (for instance, the language and keyboard settings are used in anaconda).  However, the main purpose is to write these out to the installed system at the end of installation.
These files hold the configuration settings that are either entered through the interface or through kickstart.  To some extent, they affect the installation (for instance, the language and keyboard settings are used in anaconda).  However, the main purpose is to write these out to the installed system at the end of an installation.


== Package Installation ==
== Package Installation ==
pyanaconda/compssort.py<br>
* pyanaconda/packaging/
pyanaconda/backend.py<BR>
* scripts/anaconda-yum
pyanaconda/image.py<BR>
 
pyanaconda/sortedtransaction.py<BR>
These files control the installation of files in some format to the system.  anaconda allows for multiple installation backends, though the most commonly used are yumpayload.py and livepayload.py. Each backend provides methods for selecting and removing environments, groups, and packages; configuring repos for use during and after installation; reporting progress; and so forth.  There is a well-defined API here allowing for adding additional backends.
pyanaconda/yuminstall.py


These files control package installation.  anaconda allows for multiple package installation backends, though the only real one in the tree uses yum.  Each backend provides methods for selecting groups and packages, removing groups and packages, writing out configuration settings, and so forth.
The anaconda-yum script is used to work around problems with anaconda, yum, urlgrabber, and threadsThis script does the actual installation of packages.  It is also Python.


== Installation Classes ==
== Installation Classes ==
pyanaconda/installclass.py<BR>
* pyanaconda/installclass.py
pyanaconda/installclasses/<BR>
* pyanaconda/installclasses/
pyanaconda/product.py
* pyanaconda/product.py
 


Installation classes define settings that form a sort of installation profile.  This includes steps to show and skip, product names, installation method, enabled repositories, configuration settings, and so forth.  We primarily use it to create a difference between Fedora and RHEL installs.  Other projects or ISVs could define their own installation classes for their own defaults.
Installation classes define settings that form a sort of installation profile.  This includes steps to show and skip, product names, installation method, enabled repositories, configuration settings, and so forth.  We primarily use it to create a difference between Fedora and RHEL installs.  Other projects or ISVs could define their own installation classes for their own defaults.


== Special Modes ==
== Special Modes ==
pyanaconda/kickstart.py
* pyanaconda/kickstart.py
 
[[Anaconda/Kickstart| Kickstart]] is a way of automating installations by providing anaconda with a file that contains all the data that the user would have to provide via the UI.  This file is an interface between the parser in the pykickstart package and the anaconda internals.  Now that the UI now constructs a kickstart data object in memory, this file also handles certain execution tasks as well.
 
* data/icons/
* data/liveinst/
 
These files implement installation from the live CD.  They provide some files needed to launch the installer from the live CD's desktop.  The actual live installation is handled by the appropriate packaging backend.
 
* pyanaconda/constants_text.py
* pyanaconda/installinterfacebase.py
* pyanaconda/rescue.py
* pyanaconda/text.py


[[Anaconda/Kickstart| Kickstart]] is a way of automating installations by providing anaconda with a file that contains all the data that the user would have to provide via the UI.  This file is an interface between the parser in the pykickstart package and the anaconda internals.  It primarily provides a way of saving the settings in the places anaconda expects.
These files provide the rescue mode.


data/icons<br>
== Error Handling ==
data/liveinst<br>
* pyanaconda/errors.py
liveinst/<br>
* pyanaconda/exception.py
pyanaconda/livecd.py


These files implement installation from the live CDThey provide a special installation method, a special package installation backend, and some files needed to launch the installer from the live CD's desktop.
These files control all the error reporting for anacondaerrors.py, in combination with the UI, controls displaying errors that the user can do something about or at least that anaconda can anticipate.  This is the central location for error messages.  exception.py controls a display of errors that anaconda cannot anticipate - basically, this is where unhandled exceptions get handled.  This is also where anaconda interfaces with libreport to report issues to Bugzilla.


pyanaconda/rescue.py<BR>
== Installation Control Library ==
pyanaconda/upgrade.py
* pyanaconda/install.py
* pyanaconda/progress.py
* pyanaconda/queue.py
* pyanaconda/threads.py


These files provide methods specific to rescue mode and upgrades.
This is a loose collection of important files.  install.py actually performs the installation steps, which just consists of calling out to methods throughout kickstart, anaconda, and python-blivet.  progress.py provides a way to install.py and the packaging backends to communicate with the UI for moving the progress bar and displaying messages.  queue.py is a support file that constructs communications queues, like those used in progress.py and communication.py.  Finally, threads.py handles creating and managing threads, which anaconda now extensively uses for running tasks in the background while still allowing the UI to update.


== Library ==
== Library ==
pyanaconda/__init__.py<br>
* pyanaconda/__init__.py
pyanaconda/anaconda_log.py<BR>
* pyanaconda/addons.py
pyanaconda/backend_log.py<br>
* pyanaconda/anaconda_log.py
pyanaconda/baseudev.py<br>
* pyanaconda/anaconda_optparse.py
pyanaconda/constants.py<BR>
* pyanaconda/constants.py
pyanaconda/errors.py<br>
* pyanaconda/flags.py
pyanaconda/exception.py<BR>
* pyanaconda/geoloc.py
pyanaconda/flags.py<BR>
* pyanaconda/i18n.py
pyanaconda/installmethod.py<br>
* pyanaconda/image.py
pyanaconda/isys/<BR>
* pyanaconda/indexed_dict.py
pyanaconda/iutil.py<BR>
* pyanaconda/isys/
pyanaconda/packages.py<BR>
* pyanaconda/iutil.py
pyanaconda/platform.py<br>
* pyanaconda/nm.py
pyanaconda/pyudev.py<br>
* pyanaconda/safe_dbus.py
pyanaconda/simpleconfig.py<br>
* pyanaconda/simpleconfig.py
pyanaconda/sitecustomize.py<br>
* pyanaconda/sitecustoimze.py
pyanaconda/xutils.c


These files provide a variety of miscellaneous methods that are used throughout the installer.  These functions include the logging framework, hardware probing via a udev interface, process control, handling exceptions, and other tasks.  They also contain methods that just don't fit anywhere else.
These files provide a variety of miscellaneous methods that are used throughout the installer.  These functions include the logging framework, finding the user's location via geolocation, looking up information about attached optical installation media, communicating with NetworkManager, and many other tasks.  They also contain methods that just don't fit anywhere else.


== The Main Program ==
== The Main Program ==
anaconda
* anaconda
 
This is the main anaconda program that gets called via systemd at the end of system bootup.  It handles lots of environment setup, enables updates if they exist, reads any kickstart file, sets up VNC, and other tasks.  When all this is done, it hands control over to the UI which in turn drives the rest of the installation.
 
== Startup ==
* data/systemd/
* dracut/
 
Someone with a better understanding of things than me (clumens) needs to fill this section in.
 
== Miscellaneous ==
 
* data/interactive-defaults.ks
* data/post-scripts/
 
Given that anaconda is internally building a kickstart file via the UI and then executing it, certain installation tasks are more easily implemented as kickstart scripts.  These do that.  interactive-defaults.ks is a kickstart file pulled in at the beginning of an interactive, non-kickstart installation that contains certain default settings for the UI.
 
* scripts/anaconda-cleanup
 
* scripts/instperf
* scripts/instperf.p
 
The former is a program that monitors memory usage during installation and writes out /tmp/memory.dat with this information.  The latter is a gnuplot script that interprets that file and generates a graph.  We use this to identify spikes in memory usage.
 
* scripts/makebumpver
 
* scripts/makeupdates
 
makeupdates is a tool for creating [[Anaconda/Updates|updates images]] for testing anaconda fixes. You can call it with reference to a particular tag or commit and it will build an image containing all the changes to the tree since that point.


This is the main anaconda program that gets called from the loader.  It handles lots of environment setup, enables updates if they exist, reads any kickstart file, sets up VNC, and other tasks.  When all this is done, it hands control over to the dispatcher which deals with the rest of the installation process.
* scripts/restart-anaconda


== Image Building ==
* utils/dd/
data/bootdisk/<BR>
data/command-stubs/<BR>
data/fonts/<br>
scripts/<BR>
utils/


These directories contain code that controls how the installation environment is made.  This includes creating the initial ramdisk and the
* utils/handle-sshpw
stage2 images, adding very basic versions of certain needed commands, splitting the installation tree into media-sized chunks, and other
miscellaneous tasks.


== Loader ==
* utils/logpicker
loader/
* utils/log_picker/


Coming soon.
logpicker is a tool for sending anaconda logs and other useful diagnostic information out of the installation environment in various ways (scp, ftp, Bugzilla...). It has some overlap with the graphical process that lets you submit a bug report when anaconda crashes. It has not been updated since being committed in 2010 and maybe somewhat bitrotten.


----
----
[[Category:Anaconda]]
[[Category:Anaconda]]

Latest revision as of 08:42, 8 August 2018

Source Overview

anaconda has a lot of sources, and this can be a little intimidating at first. It can be difficult to figure out where to even start looking when you're trying to track a problem down. This guide is meant as a very high-level overview of the various groups of source files and what sorts of things they cover. It's not incredibly detailed, and some source files don't want to fit into categories. Lots of pieces of functionality are spread out across multiple files. The main article about Anaconda describes where to obtain the source code, which is presently maintained in a 'git' repository.

Interface

  • pyanaconda/ui/gui/
  • pyanaconda/ui/tui/

These are the primary UI files for the interfaces supported by anaconda: graphical, text, and command line (which is really just a special form of text). Each is implemented by its own directory. For the graphical installer, the glade interface files are in the same location. For the text installer, this also includes the code required to do line-oriented input/output. There is a well-defined API here allowing for both adding additional interfaces and extending the existing interfaces with new screens.

  • pyanaconda/ui/__init__.py
  • pyanaconda/ui/common.py
  • pyanaconda/ui/communication.py
  • pyanaconda/ui/lib/

These files and directories contain code common to all supported interfaces. The first two files contain mostly base classes with code common to both the GUI and TUI. communication.py is a small file containing constants and methods for communicating between objects within the UI.

  • pyanaconda/vnc.py

This file controls setting up VNC for when it is requested during installation. Afterward, installs proceed in graphical mode.

Custom Widgets

The anaconda GUI makes use of some custom widgets. Everything listed below either implements these widgets or is needed for support.

  • widgets/data/

This directory contains images used by the timezone map widget.

  • widgets/glade/
  • widgets/python/

These two directories are support files. The glade subdirectory contains code to help glade understand these new widgets so they can be used in the interface builder. The python subdirectory contains code to allow using the widgets through gobject-introspection in a more native Python manner.

  • widgets/src

And then this is the code that implements the widgets themselves. There is one header and one source code file per widget class.

Partitioning

All partitioning code is now contained in the python-blivet package, which we also work on.

Bootloader

  • pyanaconda/bootloader.py

This file controls configuring and writing out the bootloader to the installed system. Each type of machine has its own bootloader quirks (what types of devices and filesystems are supported by the bootloader, the syntax of the config file, etc). and therefore has its own class. This file additionally handles pulling together kernel command line arguments.

Configuration

  • pyanaconda/desktop.py
  • pyanaconda/keyboard.py
  • pyanaconda/localization.py
  • pyanaconda/network.py
  • pyanaconda/ntp.py
  • pyanaconda/timezone.py
  • pyanaconda/users.py

These files hold the configuration settings that are either entered through the interface or through kickstart. To some extent, they affect the installation (for instance, the language and keyboard settings are used in anaconda). However, the main purpose is to write these out to the installed system at the end of an installation.

Package Installation

  • pyanaconda/packaging/
  • scripts/anaconda-yum

These files control the installation of files in some format to the system. anaconda allows for multiple installation backends, though the most commonly used are yumpayload.py and livepayload.py. Each backend provides methods for selecting and removing environments, groups, and packages; configuring repos for use during and after installation; reporting progress; and so forth. There is a well-defined API here allowing for adding additional backends.

The anaconda-yum script is used to work around problems with anaconda, yum, urlgrabber, and threads. This script does the actual installation of packages. It is also Python.

Installation Classes

  • pyanaconda/installclass.py
  • pyanaconda/installclasses/
  • pyanaconda/product.py

Installation classes define settings that form a sort of installation profile. This includes steps to show and skip, product names, installation method, enabled repositories, configuration settings, and so forth. We primarily use it to create a difference between Fedora and RHEL installs. Other projects or ISVs could define their own installation classes for their own defaults.

Special Modes

  • pyanaconda/kickstart.py

Kickstart is a way of automating installations by providing anaconda with a file that contains all the data that the user would have to provide via the UI. This file is an interface between the parser in the pykickstart package and the anaconda internals. Now that the UI now constructs a kickstart data object in memory, this file also handles certain execution tasks as well.

  • data/icons/
  • data/liveinst/

These files implement installation from the live CD. They provide some files needed to launch the installer from the live CD's desktop. The actual live installation is handled by the appropriate packaging backend.

  • pyanaconda/constants_text.py
  • pyanaconda/installinterfacebase.py
  • pyanaconda/rescue.py
  • pyanaconda/text.py

These files provide the rescue mode.

Error Handling

  • pyanaconda/errors.py
  • pyanaconda/exception.py

These files control all the error reporting for anaconda. errors.py, in combination with the UI, controls displaying errors that the user can do something about or at least that anaconda can anticipate. This is the central location for error messages. exception.py controls a display of errors that anaconda cannot anticipate - basically, this is where unhandled exceptions get handled. This is also where anaconda interfaces with libreport to report issues to Bugzilla.

Installation Control Library

  • pyanaconda/install.py
  • pyanaconda/progress.py
  • pyanaconda/queue.py
  • pyanaconda/threads.py

This is a loose collection of important files. install.py actually performs the installation steps, which just consists of calling out to methods throughout kickstart, anaconda, and python-blivet. progress.py provides a way to install.py and the packaging backends to communicate with the UI for moving the progress bar and displaying messages. queue.py is a support file that constructs communications queues, like those used in progress.py and communication.py. Finally, threads.py handles creating and managing threads, which anaconda now extensively uses for running tasks in the background while still allowing the UI to update.

Library

  • pyanaconda/__init__.py
  • pyanaconda/addons.py
  • pyanaconda/anaconda_log.py
  • pyanaconda/anaconda_optparse.py
  • pyanaconda/constants.py
  • pyanaconda/flags.py
  • pyanaconda/geoloc.py
  • pyanaconda/i18n.py
  • pyanaconda/image.py
  • pyanaconda/indexed_dict.py
  • pyanaconda/isys/
  • pyanaconda/iutil.py
  • pyanaconda/nm.py
  • pyanaconda/safe_dbus.py
  • pyanaconda/simpleconfig.py
  • pyanaconda/sitecustoimze.py

These files provide a variety of miscellaneous methods that are used throughout the installer. These functions include the logging framework, finding the user's location via geolocation, looking up information about attached optical installation media, communicating with NetworkManager, and many other tasks. They also contain methods that just don't fit anywhere else.

The Main Program

  • anaconda

This is the main anaconda program that gets called via systemd at the end of system bootup. It handles lots of environment setup, enables updates if they exist, reads any kickstart file, sets up VNC, and other tasks. When all this is done, it hands control over to the UI which in turn drives the rest of the installation.

Startup

  • data/systemd/
  • dracut/

Someone with a better understanding of things than me (clumens) needs to fill this section in.

Miscellaneous

  • data/interactive-defaults.ks
  • data/post-scripts/

Given that anaconda is internally building a kickstart file via the UI and then executing it, certain installation tasks are more easily implemented as kickstart scripts. These do that. interactive-defaults.ks is a kickstart file pulled in at the beginning of an interactive, non-kickstart installation that contains certain default settings for the UI.

  • scripts/anaconda-cleanup
  • scripts/instperf
  • scripts/instperf.p

The former is a program that monitors memory usage during installation and writes out /tmp/memory.dat with this information. The latter is a gnuplot script that interprets that file and generates a graph. We use this to identify spikes in memory usage.

  • scripts/makebumpver
  • scripts/makeupdates

makeupdates is a tool for creating updates images for testing anaconda fixes. You can call it with reference to a particular tag or commit and it will build an image containing all the changes to the tree since that point.

  • scripts/restart-anaconda
  • utils/dd/
  • utils/handle-sshpw
  • utils/logpicker
  • utils/log_picker/

logpicker is a tool for sending anaconda logs and other useful diagnostic information out of the installation environment in various ways (scp, ftp, Bugzilla...). It has some overlap with the graphical process that lets you submit a bug report when anaconda crashes. It has not been updated since being committed in 2010 and maybe somewhat bitrotten.