Re^2: Building a web-based system administration interface in Perl

DON'T use yum/apt-get/emerge/rpm to install plugins. Not all distributions use that tools, some use other tools, some don't use package managers at all. Distributing plugins should be easy. Having to generate 5 or 10 different package formats, each with 5 or 10 different packages for different distribution versions, ist just too much work. The Webmin way, a renamed and compressed tar file, works quite well. We could discuss if we want old or new style tars, with or without GNU extensions, or some other archive format, like arj, lha, cpio or zip.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Comment on Re^2: Building a web-based system administration interface in Perl

Replies are listed 'Best First'.
Re^3: Building a web-based system administration interface in Perl by jdrago_999 (Hermit) on Apr 08, 2009 at 23:53 UTC
DON'T use yum/apt-get/emerge/rpm to install plugins. They certainly have their problems, but reinventing the software-installation wheel might not be a solution. I like the idea of writing a simple plugin like this (thinking out loud here): `Given httpd is installed When update is available Then notify me@my-email.com` [download]	[reply] [d/l]
Re^4: Building a web-based system administration interface in Perl by afoken (Chancellor) on Apr 09, 2009 at 07:18 UTC
I don't want to reinvent the wheel. But I also do not want do create 20 different bundles for each and every plugin just because the various OSes and OS distributions use different package managers. If the OS maintainers wish to make the new tool available, they can pack it into their kind of bundle. Debian, SuSE, and Redhat do exactly this with perl and thousands of other software packages. Most (all) "perl plugins" on CPAN are distributed as tar files, and some of them are repackaged into OS specific bundles if the OS maintainers like them. This works quite well, and completely eliminates the need to generate something else than simple tar files for plugin authors. Your idea of an update poller looks more like a job for the OS specific package manager, combined with cron. Webmin and the new tool work as web-based tool, which is a completely different thing. Of course, it would be possible to write a plugin that installs such a cron job and takes care of poll interval, notification address, and selected packages. The cron script could be part of the plugin, but it would better be part of the package manager, or a plugin for the package manager. That way, every user of the OS could use the notification tool, even if they do not want to install Webmin or the new tool. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply]