[新闻]请停止使用Automatix,对系统有害。
- zhuqin_83
- 帖子: 10606
- 注册时间: 2006-05-13 4:02
- 联系:
[新闻]请停止使用Automatix,对系统有害。
本来安装automatix是为了方便新手安装一些系统默认不装的软件、解码器等等,但最近研究表明,automatix很可能破坏系统,以下是详细报告,结论是automatix没有必要,推荐的软件安装方式还是新立得。
另外,ubuntu官方也认为automatix有害健康,这个项目基本上完蛋了。如果有朋友仍然使用这个软件的话,请彻底把他请出你的系统吧。
**********************************************************************************
https://wiki.ubuntu.com/UbuntuWeeklyNew ... 9744de7809
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. [WWW] http://mjg59.livejournal.com/77440.html
**********************************************************************************
http://distrowatch.com/weekly.php?issue=20070806#news
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."
**********************************************************************************
http://mjg59.livejournal.com/77440.html
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.
另外,ubuntu官方也认为automatix有害健康,这个项目基本上完蛋了。如果有朋友仍然使用这个软件的话,请彻底把他请出你的系统吧。
**********************************************************************************
https://wiki.ubuntu.com/UbuntuWeeklyNew ... 9744de7809
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. [WWW] http://mjg59.livejournal.com/77440.html
**********************************************************************************
http://distrowatch.com/weekly.php?issue=20070806#news
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."
**********************************************************************************
http://mjg59.livejournal.com/77440.html
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.
上次由 zhuqin_83 在 2007-10-18 11:44,总共编辑 2 次。
HP Pavilion DV6-2064CA: AMD Turion II Ultra Dual-Core Mobile M640, HD4650, 2GBx2 DDR2-800, Seagate 500GB 7200RPM SATA, BD-ROM
DELL UltraSharp 2209WA
Arch64, Testing repo
DELL UltraSharp 2209WA
Arch64, Testing repo
- momova
- 帖子: 3381
- 注册时间: 2007-07-11 21:43
- 系统: archlinux
- 来自: 东江边
- skyx
- 论坛版主
- 帖子: 9202
- 注册时间: 2006-12-23 13:46
- 来自: Azores Islands
- 联系:
- zhuqin_83
- 帖子: 10606
- 注册时间: 2006-05-13 4:02
- 联系:
- zhuqin_83
- 帖子: 10606
- 注册时间: 2006-05-13 4:02
- 联系:
Is Automatix2 safe? Folks in #ubuntu on IRC keep telling me it isn't.
* Yes, it is perfectly safe. Thousands of users worldwide use Automatix2 every day without any issues. If you think you have run into any issues related to Automatix, please report to our forums to get quick and high quality support.
* Yes, it is perfectly safe. Thousands of users worldwide use Automatix2 every day without any issues. If you think you have run into any issues related to Automatix, please report to our forums to get quick and high quality support.
HP Pavilion DV6-2064CA: AMD Turion II Ultra Dual-Core Mobile M640, HD4650, 2GBx2 DDR2-800, Seagate 500GB 7200RPM SATA, BD-ROM
DELL UltraSharp 2209WA
Arch64, Testing repo
DELL UltraSharp 2209WA
Arch64, Testing repo
- zhuqin_83
- 帖子: 10606
- 注册时间: 2006-05-13 4:02
- 联系:
Does Automatix2 break Ubuntu upgrades?
* The chances of Automatix being behind the breaking of a Ubuntu upgrade is as high as the packages which Ubuntu releases for that release and the subsequent one. Most of what Automatix installs comes directly from the Ubuntu repositories and is installed using apt-get (just like in synaptic and Add/Remove). It is more likely that an upgrade problem lies upstream in the Ubuntu repositories. In fact Ubuntu has been notorious for breaking xserver packages several times on stable releases in the past. They have also been extremely notorious for passing on the blame to Automatix for their own failings (which they still haven't stopped doing). It is unfortunate that many people actually believe in this FUD and help spread it even further rather than trying to investigate the real cause of a breakage.
* The chances of Automatix being behind the breaking of a Ubuntu upgrade is as high as the packages which Ubuntu releases for that release and the subsequent one. Most of what Automatix installs comes directly from the Ubuntu repositories and is installed using apt-get (just like in synaptic and Add/Remove). It is more likely that an upgrade problem lies upstream in the Ubuntu repositories. In fact Ubuntu has been notorious for breaking xserver packages several times on stable releases in the past. They have also been extremely notorious for passing on the blame to Automatix for their own failings (which they still haven't stopped doing). It is unfortunate that many people actually believe in this FUD and help spread it even further rather than trying to investigate the real cause of a breakage.
HP Pavilion DV6-2064CA: AMD Turion II Ultra Dual-Core Mobile M640, HD4650, 2GBx2 DDR2-800, Seagate 500GB 7200RPM SATA, BD-ROM
DELL UltraSharp 2209WA
Arch64, Testing repo
DELL UltraSharp 2209WA
Arch64, Testing repo
- zhuqin_83
- 帖子: 10606
- 注册时间: 2006-05-13 4:02
- 联系:
Does Automatix2 alter configuration files, and if so does it make a backup?
* Yes, Automatix2 makes date and time based backups of all files that it alters in the same folders where they exist.
* Yes, Automatix2 makes date and time based backups of all files that it alters in the same folders where they exist.
HP Pavilion DV6-2064CA: AMD Turion II Ultra Dual-Core Mobile M640, HD4650, 2GBx2 DDR2-800, Seagate 500GB 7200RPM SATA, BD-ROM
DELL UltraSharp 2209WA
Arch64, Testing repo
DELL UltraSharp 2209WA
Arch64, Testing repo
- skyx
- 论坛版主
- 帖子: 9202
- 注册时间: 2006-12-23 13:46
- 来自: Azores Islands
- 联系:
- zhuqin_83
- 帖子: 10606
- 注册时间: 2006-05-13 4:02
- 联系:
源里的东西还算好的,问题是他还有一部分脚本有问题,软件甚至是压缩包的。skyx 写了:damage to small items of your configuration, up to and including the potential to leave your system in an unbootable state.
有这句就可以置顶了,还好,我没装这个东东,只是镜像过这个东东的源。
HP Pavilion DV6-2064CA: AMD Turion II Ultra Dual-Core Mobile M640, HD4650, 2GBx2 DDR2-800, Seagate 500GB 7200RPM SATA, BD-ROM
DELL UltraSharp 2209WA
Arch64, Testing repo
DELL UltraSharp 2209WA
Arch64, Testing repo
- skyx
- 论坛版主
- 帖子: 9202
- 注册时间: 2006-12-23 13:46
- 来自: Azores Islands
- 联系:
- zhuqin_83
- 帖子: 10606
- 注册时间: 2006-05-13 4:02
- 联系:
- skyx
- 论坛版主
- 帖子: 9202
- 注册时间: 2006-12-23 13:46
- 来自: Azores Islands
- 联系:
- skyx
- 论坛版主
- 帖子: 9202
- 注册时间: 2006-12-23 13:46
- 来自: Azores Islands
- 联系:
- karron
- 帖子: 6226
- 注册时间: 2005-06-11 14:03
- 来自: 不明真相的群众
- 联系:
ubuntu好几个版本之前, 我看到官方发布的版本升级报告中就提到说使用这个软件配置过的系统, 在进行版本升级的时候可能会遭遇失败. 没想到ubuntu现在还正式发了这样一篇文章, 这个项目算挂了.
不过我一直对这个软件兴趣不大, 也没有怎么关注, 国内用的人也很少吧. 因为他的源在国外, 使用他安装配置的软件下载起来很慢的. 我们有ubuntu-cn, 有些官方源里面没有的软件这个里面可以找到.
不过我一直对这个软件兴趣不大, 也没有怎么关注, 国内用的人也很少吧. 因为他的源在国外, 使用他安装配置的软件下载起来很慢的. 我们有ubuntu-cn, 有些官方源里面没有的软件这个里面可以找到.
我的blog,关于技术,软件,linux,vim <---- 所有博客均被河蟹.