ºìÁªLinuxÃÅ»§
Linux°ïÖú
µ±Ç°Î»ÖÃ: ºìÁªLinuxÃÅ»§ > Ubuntu

UbuntuµÄÓû§ÃÇ£¬ÇëֹͣʹÓÃAutomatix£¬¶ÔϵͳÓк¦

·¢²¼Ê±¼ä:2007-08-10 16:41:46À´Ô´:ºìÁª×÷Õß:Uaprjuy
±¾À´°²×°automatixÊÇΪÁË·½±ãÐÂÊÖ°²×°Ò»Ð©ÏµÍ³Ä¬Èϲ»×°µÄÈí¼þ¡¢½âÂëÆ÷µÈµÈ£¬µ«×î½üÑо¿±íÃ÷£¬automatixºÜ¿ÉÄÜÆÆ»µÏµÍ³£¬ÒÔÏÂÊÇÏêϸ±¨¸æ£¬½áÂÛÊÇautomatixûÓбØÒª£¬ÍƼöµÄÈí¼þ°²×°·½Ê½»¹ÊÇÐÂÁ¢µÃ¡£

ÁíÍ⣬ubuntu¹Ù·½Ò²ÈÏΪautomatixÓк¦½¡¿µ£¬Õâ¸öÏîÄ¿»ù±¾ÉÏÍêµ°ÁË¡£Èç¹ûÓÐÅóÓÑÈÔȻʹÓÃÕâ¸öÈí¼þµÄ»°£¬Çë³¹µ×°ÑËûÇë³öÄãµÄϵͳ°É¡£

Automatix: Package Architecture Could Lead to Serious System Problems

Automatix is a configuration/package installation tool which has made it easier for users to install graphics drivers, media codecs and software not part of the Ubuntu Distribution. This review of the package shows that Automatix has some serious problems, and in its current state is dangerous to your system. Potential problems run the range from damage to small items of your configuration, up to and including the potential to leave your system in an unbootable state. Read the point by point analysis by following the link to the review.


In the meanwhile, Ubuntu's Matthew Garrett has created a stir when he published the findings about Automatix, a popular third-party software utility that significantly extends the capabilities of a desktop Ubuntu system. The report concludes that Automatix is "actively dangerous to Ubuntu." The report provides a very long list of issues found in the Automatix code, ranging from cosmetic ones, such as missing man-pages, to serious problems, such as lack of dependency management or potential race conditions that could seriously damage the installed system. The author has found that Automatix is not only unsupportable in its present state, the design of the software package makes it impossible to fix its problems. Nevertheless, the report also suggests that the functionality provided by Automatix could still be implemented: "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."


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.

o It is inappropriately flagged as belonging to base
o Depends on essential packages
o Has a short description of more than 80 characters and no long description
o Provides no email address in the maintainer field
o Contains no copyright information in the standard locations
o Ships a TODO file as a control file
o Provides no man pages
o Ships files in /usr/etc
o Contains many files inappropriately flagged as executable
o 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.
* 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 dpkg

May 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.
ÎÄÕÂÆÀÂÛ

¹²ÓÐ 0 ÌõÆÀÂÛ