Matthew Garrett (![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} mjg59) wrote,@ 2007-08-04 03:59:00 |
|
| Entry tags: | advogato, ubuntu |
Anyway, back to pure Linux stuff. A while ago, the Ubuntu Technical Board were asked to take a look at Automatix. I've finally got around to doing so, and here are my initial conclusions. I'd appreciate any factual corrections, and note that at this point this is my individual opinion rather than any sort of official statement.
Automatix is a combination system configuration/package installation
tool, aimed at making it easy for users to install features like
graphics drivers, media codecs and software not distributed as part of
the Ubuntu distribution. It is provided as a .deb file containing a
python GUI frontend that calls out to a shell backend. The frontend
parses an XML file which contains module descriptions and function
names for installing and uninstalling modules, with these functions
being part of the shell backend. An install module will typically
check whether another package manager is running, and if not either
install a set of debs or download and manually install a
tarball. Uninstall modules generally remove the same software or clean
up the manually installed files.
The following is a list of identified issues with the current version
of Automatix - it is the result of a few hours of investigation, so
may not be complete.
- Automatix is, in itself, a poor quality package which fails to
conform to Debian or Ubuntu policy.- It is inappropriately flagged as belonging to base
- Depends on essential packages
- Has a short description of more than 80 characters and no long
description - Provides no email address in the maintainer field
- Contains no copyright information in the standard locations
- Ships a TODO file as a control file
- Provides no man pages
- Ships files in /usr/etc
- Contains many files inappropriately flagged as executable
- Changelog is in /usr/etc/automatix2/ax_data ?
These issues are primarily cosmetic and in themselves are unlikely to
cause any harm to the system. - It is inappropriately flagged as belonging to base
- In debug mode, automatix will write files to your home directory as
root. Again, more of an irritation than anything dangerous. - Provides platform-specific data in /usr/share. Potentially an issue
if /usr/share is shared between multiple architectures, but since
Automatix is x86/amd64 only probably not a real problem. #!/bin/bash #created by arnieboy foo=`gksudo -u root -k -m "enter your password for gedit root access" /bin/echo "Do you have root access?"` sudo gedit $NAUTILUS_SCRIPT_SELECTED_URIS
appears to be an attempt to ensure that the user has sudo rights. This
will break if timestamp_timeout is set to 0 in sudoers - gedit should
be run directly from gksudo. This is repeated in more than one
place. The assumption that sudo will not need to prompt appears
prevalent throughout the code.- catagory_data.xml - nitpick, but should be category
- "Please NOTE that downloading and installing w32codecs, libdvdcss2
and other non-free codecs without paying a fee to the concerned
authorities constitutes a CRIME in the United States of America"
Somewhat dubious legal advice - the issue has nothing to do with fees,
and isn't just limited to the USA. - Automatix checks that other package managers aren't running at
startup (by grepping for a static list of application names in the
proces list), but doesn't enforce this by carrying out any locking of
its own. This leaves Automatix open to race conditions. if ps -U root -u root u | grep "dpkg" | grep -v grep; then killall -9 dpkgMay well leave the system in an inconsistent and unbootable state, and
is carried out without warning. This is entirely unacceptable and will
leave a stale lockfile in any case.function reloadnautilus { killall -9 nautilus }Not actually used anywhere, but could potentially lose user
information without warning.- Most install functions contain a sleep statement for no obvious
reason. They then call dpkg_check, which sleeps again. It's not at all
clear what this is meant to be doing. - Passes --assume-yes to apt-get, which will (as a result) happily
remove packages without giving the user an opportunity to
intervene. This is especially bad when removing Automatix modules -
any package that depends on one of the packages being removed will
also be uninstalled, even if the package was originally installed via
something other than Automatix! - Has no internal dependency management. Unable to keep track of why
packages were installed, so prevents the removal of the multimedia
module because that would remove sections of other modules without
explicitly removing that module. Installing swiftfoxplugins will pull
in several plugin packages, but removing swiftfoxplugins will not
remove them even if nothing else depends on them. Also means that
package installation and uninstallation have to be manually kept in
sync - uninstall will not always remove all packages that were
installed. - Has no concept of file tracking, so will just remove entire
directories. Makes no attempt to ensure that a user-installed version
is not already installed in the same location, so effectively assumes
that the /opt namespace belongs to it. - Will remove Ubuntu repository packages in favour of tarballs with
no warning. - Setting ctrl-alt-del to open gnome system monitor will destroy any
existing user configuration for run_command_9 - Installing streamtuner will create a world writable directory in
/opt/ripped with no sticky bit, allowing users to interfere with other
users' files. - mplayerplugin moves totem plugin files to a backup, but does
nothing to prevent package upgrades of totem replacing them. - Only updates the java link after installing new java, not the rest
of the java alternatives - amsninstall installs tls libs that are never removed, copying over
the ones in the tcltls package. This means that the md5sums in the
tcltls package will no longer validate. sudo ln -s /usr/lib/libesd.so.0 /usr/lib/libesd.so.1
is really not
such a good idea.ln -s /tmp/.esd-1000 /tmp/.esd
looks like it'll only ever work for
the first user on the system, and there's nothing to recreate it on
boot.sudo sed -i "s/^vboxusers\(.*\):$/vboxusers\1:$AXUSER/" /etc/group
- assumes that the system isn't using some sort of user directory
service.- installs truecrypt suid root - not ideal, given its less than
stellar security record - Unmounts filesystems without checking to ensure that the unmount
succeeded. - Deletes lines from fstab and replaces them with device nodes
rather than uuids. - Includes acroread 7.0.9, despite the new Acrobat license appearing
to grant no right to redistribute.
Conclusion:
Automatix exists to satisfy a genuine need, and further work should be
carried out to determine whether these user requirements can be
satisfied within the distribution as a whole. However, in its current
form Automatix is actively dangerous to systems - ranging from damage
to small items of user configuration, through removing user-installed
packages without adequate prompting or warning and up to the (small
but existing) potential to leave a system in an unbootable state.
The current design of Automatix precludes any reasonable way to fix
some of these problems. It is attempting to fulfil the role of a
high-level package manager without actually handling any sort of
dependency resolution itself.
A more reasonable method of integrating Automatix's functionality into
Ubuntu would be for the Automatix team to provide deb files to act as
installers for the software currently provided. These could then be
installed through the existing package manager interfaces. This would
solve many of the above problems while still providing the same level
of functionality.
In its current form Automatix is unsupportable, and a mechanism for
flagging bugs from machines with Automatix installed may provide a
valuable aid for determining whether issues are due to supported
distribution packages or third party software installers.
