You can subscribe to this list here.
2001 |
Jan
(13) |
Feb
(24) |
Mar
(23) |
Apr
(11) |
May
(18) |
Jun
(90) |
Jul
(29) |
Aug
(26) |
Sep
(37) |
Oct
(10) |
Nov
(31) |
Dec
(11) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(45) |
Feb
(18) |
Mar
(12) |
Apr
(7) |
May
(10) |
Jun
(62) |
Jul
(8) |
Aug
(40) |
Sep
(41) |
Oct
(43) |
Nov
(29) |
Dec
(36) |
2003 |
Jan
(25) |
Feb
(9) |
Mar
(11) |
Apr
(13) |
May
(19) |
Jun
(19) |
Jul
(11) |
Aug
(4) |
Sep
(109) |
Oct
(73) |
Nov
(69) |
Dec
(21) |
2004 |
Jan
(21) |
Feb
(33) |
Mar
(31) |
Apr
(25) |
May
(33) |
Jun
(42) |
Jul
(47) |
Aug
(12) |
Sep
(41) |
Oct
(47) |
Nov
(30) |
Dec
(19) |
2005 |
Jan
(6) |
Feb
(23) |
Mar
(21) |
Apr
(26) |
May
(21) |
Jun
(16) |
Jul
(17) |
Aug
(7) |
Sep
(8) |
Oct
(13) |
Nov
(7) |
Dec
(10) |
2006 |
Jan
(10) |
Feb
(3) |
Mar
|
Apr
(2) |
May
|
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(4) |
2007 |
Jan
(2) |
Feb
(3) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(6) |
Jul
(6) |
Aug
(8) |
Sep
(3) |
Oct
(21) |
Nov
(4) |
Dec
(6) |
2008 |
Jan
(11) |
Feb
(28) |
Mar
(26) |
Apr
(9) |
May
(2) |
Jun
(10) |
Jul
(1) |
Aug
(20) |
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
(4) |
Feb
(10) |
Mar
(1) |
Apr
(24) |
May
(22) |
Jun
(18) |
Jul
(15) |
Aug
(21) |
Sep
(4) |
Oct
(7) |
Nov
(6) |
Dec
|
2010 |
Jan
|
Feb
(2) |
Mar
(13) |
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
(4) |
Sep
(6) |
Oct
(1) |
Nov
(1) |
Dec
|
2011 |
Jan
(18) |
Feb
(2) |
Mar
(23) |
Apr
(4) |
May
(5) |
Jun
(1) |
Jul
|
Aug
|
Sep
(9) |
Oct
|
Nov
(5) |
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
(31) |
Apr
(3) |
May
|
Jun
(2) |
Jul
(6) |
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
(7) |
2014 |
Jan
|
Feb
(1) |
Mar
(9) |
Apr
(4) |
May
(7) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(4) |
Dec
|
2016 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Jaldhar H. V. <ja...@de...> - 2004-06-13 05:22:00
|
Jamie, Can you comment on the recent security flaws discovered in usermin and webmin, the ones that were fixed for 1.080 and 1.150? What exactly are the issues? The Japanese group SAN put out advisories but they're rather low on detail. Am I right that there are no known exploits at this time? Also could you provide a diff of the security changes only vis-a-vis 1.070/1.140? The Debian security team would like to take a look. Thanks in advance. -- Jaldhar H. Vyas <ja...@de...> La Salle Debain - http://www.braincells.com/debian/ |
From: Pantaleo, F. <FPa...@ro...> - 2004-06-09 17:25:58
|
Hi All, =20 I have been playing with the possibility of writing a Oracle Webmin module. Has this been done ? Are their other guides to developing new webmin modules ? =20 Thx Frank Pantaleo |
From: Jamie C. <jca...@we...> - 2004-06-08 23:05:05
|
On Tue, 2004-06-08 at 12:38, Jaldhar H. Vyas wrote: > On Sun, 7 Jun 2004, Jamie Cameron wrote: > > > Yes.. I presume you only create .deb packages for the standard modules, > > and not for any third-party modules? > > > > well there's a couple of third-party modules--exim and snort. And i'm > missing a couple of standard modules that don't apply or deal with > obsolete software such as sgiexports or majordomo but by and large yes. > There are some other people who maintain packages of other third-party > modules though. > > > > > which seems > > > > to be the core problem here. > > > > > > > > > > Also what about cloned modules? Currently rpm and dpkg can't deal with > > > those at all. > > > > That's a whole other problem :-( > > > > The current method via which cloning is done is not optimal, as clones > > are not stored in /etc/webmin as they should be. Perhaps introducing > > support for multiple root directories could help solve this too, but > > creating clones as links under some /etc/webmin/clones directory, rather > > than links in /usr/libexec/webmin .. > > > > It seems to me the multiple root idea is the cleanest all around. But in > the end it is what is easiest for you that counts. I'll have a look into implementing multiple roots then, when I get the chance. Some of the work has been done already, in order to support themes. - Jamie |
From: Martin M. <mm...@me...> - 2004-06-08 17:19:18
|
###################################################################### History: -------- 07.06.2004 Usermin-Development-Version 1.081 released 04.06.2004 Virtualmin-Version 2.00 released as stable 03.06.2004 Webmin-Version 1.150 released as stable Usermin-Version 1.080 released as stable 28.05.2004 Webmin-Development-Version 1.149 released ###################################################################### Current Stable Release for Webmin is 1.150 http://prdownloads.sourceforge.net/sourceforge/webadmin/webmin-1.150.tar.gz http://prdownloads.sourceforge.net/webadmin/webmin-1.150-1.noarch.rpm http://webmin.mamemu.de/devel/tarballs/webmin-1.150-minimal.tar.gz Current Development Release for Webmin is 1.150 http://prdownloads.sourceforge.net/sourceforge/webadmin/webmin-1.150.tar.gz http://prdownloads.sourceforge.net/webadmin/webmin-1.150-1.noarch.rpm http://webmin.mamemu.de/devel/tarballs/webmin-1.150-minimal.tar.gz Current Stable Release for Usermin is 1.080 http://prdownloads.sourceforge.net/webadmin/usermin-1.080.tar.gz http://prdownloads.sourceforge.net/webadmin/usermin-1.080-1.noarch.rpm http://webmin.mamemu.de/devel/tarballs/usermin-1.080.tar.gz Current Development Release for Usermin is 1.081 http://prdownloads.sourceforge.net/webadmin/usermin-1.081.tar.gz http://prdownloads.sourceforge.net/webadmin/usermin-1.081-1.noarch.rpm http://webmin.mamemu.de/devel/tarballs/usermin-1.081.tar.gz Current Stable Release for VirtualMin is 2.00 http://webmin.mamemu.de/download/virtualmin/virtual-server-2.00.wbm.gz ###################################################################### If you are anoyed by these post you can filter this with procmail scanning for X-Webmin: update in the header. kind regards Martin Mewes |
From: Jaldhar H. V. <ja...@de...> - 2004-06-08 02:39:33
|
On Sun, 7 Jun 2004, Jamie Cameron wrote: > Yes.. I presume you only create .deb packages for the standard modules, > and not for any third-party modules? > well there's a couple of third-party modules--exim and snort. And i'm missing a couple of standard modules that don't apply or deal with obsolete software such as sgiexports or majordomo but by and large yes. There are some other people who maintain packages of other third-party modules though. > > > which seems > > > to be the core problem here. > > > > > > > Also what about cloned modules? Currently rpm and dpkg can't deal with > > those at all. > > That's a whole other problem :-( > > The current method via which cloning is done is not optimal, as clones > are not stored in /etc/webmin as they should be. Perhaps introducing > support for multiple root directories could help solve this too, but > creating clones as links under some /etc/webmin/clones directory, rather > than links in /usr/libexec/webmin .. > It seems to me the multiple root idea is the cleanest all around. But in the end it is what is easiest for you that counts. -- Jaldhar H. Vyas <ja...@de...> La Salle Debain - http://www.braincells.com/debian/ |
From: Jamie C. <jca...@we...> - 2004-06-07 23:12:39
|
Sure - in your theme's functions file, create a function called theme_icons_table. This will be called instead of icons_table, and can output whatever table HTML you like.. - Jamie On Tue, 2004-06-08 at 03:44, Joe Cooper wrote: > Hey Jamie and all, > > I'm making a new theme, and I'd like to remove the borders from the > icon_tables routine. Presumably this would make all modules that > display icons display them without a border. > > Is there a clean way to override this function without overriding all of > web-lib? > > Thanks! > > > ------------------------------------------------------- > This SF.Net email is sponsored by: GNOME Foundation > Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. > GNOME Users and Developers European Conference, 28-30th June in Norway > http://2004/guadec.org > - > Forwarded by the Webmin development list at web...@we... > To remove yourself from this list, go to > http://lists.sourceforge.net/lists/listinfo/webadmin-devel |
From: Joe C. <jo...@sw...> - 2004-06-07 17:44:05
|
Hey Jamie and all, I'm making a new theme, and I'd like to remove the borders from the icon_tables routine. Presumably this would make all modules that display icons display them without a border. Is there a clean way to override this function without overriding all of web-lib? Thanks! |
From: Jamie C. <jca...@we...> - 2004-06-07 00:11:32
|
On Sun, 2004-06-06 at 12:48, Jaldhar H. Vyas wrote: > Apologies for the late reply. I had to drop everything due to a heavy > work load. > > On Tue, 2 Jun 2004, Jamie Cameron wrote: > > > Having two root directories is neat, but may confuse some modules. A lot > > of them are written to assume that all module directories lie under the > > same root, and access files in other modules with paths like > > ../othermodule/somefile.pl . This could be fixed for the core modules, > > but may break third-party code .. > > > > Shouldn't they be using defined APIs like foreign_call etc? Then it would > just be a matter of patching those few functions in web-lib.pl Ideally, yes :-) However, not all do .. Fortunately, very few modules seem to be like this, so not many would be broken .. and certainly none of the core modules. > > I still think having one root directory is best, as long as there is no > > possibility of modules from .deb packages being overwritten, > > and vice-versa... Yes.. I presume you only create .deb packages for the standard modules, and not for any third-party modules? > > which seems > > to be the core problem here. > > > > Also what about cloned modules? Currently rpm and dpkg can't deal with > those at all. That's a whole other problem :-( The current method via which cloning is done is not optimal, as clones are not stored in /etc/webmin as they should be. Perhaps introducing support for multiple root directories could help solve this too, but creating clones as links under some /etc/webmin/clones directory, rather than links in /usr/libexec/webmin .. - Jamie |
From: Jaldhar H. V. <ja...@de...> - 2004-06-06 03:03:49
|
On Tue, 2 Jun 2004, Jamie Cameron wrote: > > Maybe Webmin can be modified to built a deb on the fly out of a wbm and > > install that instead of the wbm? > > Interesting idea .. perhaps Jaldhar could comment on this one? > Well I tried to write a wbm to deb converter. It didn't quite work in all cases. Maybe with a bit more effort it could. But another problem is there isn't always a one-to-one correspondence between .debs and modules. e.g. webmin-core contains the at, cron, init, lilo, man, mount, net, pam, proc, raid, shell, and syslog modules. Apt-get always refuses to install a package when it overlaps with another. -- Jaldhar H. Vyas <ja...@de...> La Salle Debain - http://www.braincells.com/debian/ |
From: Jaldhar H. V. <ja...@de...> - 2004-06-06 02:49:44
|
Apologies for the late reply. I had to drop everything due to a heavy work load. On Tue, 2 Jun 2004, Jamie Cameron wrote: > Having two root directories is neat, but may confuse some modules. A lot > of them are written to assume that all module directories lie under the > same root, and access files in other modules with paths like > ../othermodule/somefile.pl . This could be fixed for the core modules, > but may break third-party code .. > Shouldn't they be using defined APIs like foreign_call etc? Then it would just be a matter of patching those few functions in web-lib.pl > I still think having one root directory is best, as long as there is no > possibility of modules from .deb packages being overwritten, and vice-versa... > which seems > to be the core problem here. > Also what about cloned modules? Currently rpm and dpkg can't deal with those at all. -- Jaldhar H. Vyas <ja...@de...> La Salle Debain - http://www.braincells.com/debian/ |
From: Martin M. <mm...@me...> - 2004-06-04 13:08:22
|
Hi Jamie, Am Freitag, 4. Juni 2004 00:55 schrieb Jamie Cameron: > > Would it be hard to implement an automatic page refresh like it is in > > the Mailbox-Module? > > Sure .. I should be able to sneak that into the 1.150 release. confirmed ... :-) Another question on this. Especially the module itself. We will upgrade our backup-server to an external SCSI-HDD-Tower with 8*148= =20 GiB SCSI-HDDs plus one TapeDevice. Our Backup-Server itself will have no HDDs anymore in it afterwards. The basic installation will be ... /dev/sda1 /boot -> 50 MiB ext3 /dev/sda2 /swap -> 1 GiB /dev/sda3 / -> 5 GiB ext3 /dev/sda4 none -> 141,95 GiB Linux RAID /dev/sdb1 none -> 148 Gib Linux RAID /dev/sdc1 none -> 148 Gib Linux RAID /dev/sdd1 none -> 148 Gib Linux RAID /dev/sde1 none -> 148 Gib Linux RAID /dev/sdf1 none -> 148 Gib Linux RAID /dev/sdg1 none -> 148 Gib Linux RAID /dev/sdh1 none -> 148 Gib Linux RAID After that is the module ready to do the following (or similar): "There are partitions reserved to be part of a Linux RAID-System. Currently= =20 there is no Linux-RAID on your system. Please indicate, which type of RAID= =20 you want." <dropdownbox to select from stripeset to raid x> (next steps would be for my scenario) "You have requested to install a RAID 5 system. Should all reserved partion= s=20 go into that RAID-System?" [ ] Yes (Now Webmin should come up with a reasonable solution, maybe saying) "If you click on this button the basic RAID 5 system will be configured as= =20 follows ..." (maybe) /dev/sda4 Parity Partition 141,95 GiB /dev/sdb1 to /dev/sdh1 Data Storage aprox. 1036 TiB (what I mean is, that there should be a check if a requested type of RAID i= s=20 possible with the found HDDs or not, and to show up a possible solution to= =20 take) "The basic RAID 5 system has been setup properly. Now you need to choose=20 which filesystem this RAID should have." <dropdownbox with possible filesystems> (what I mean is, that the module should automagically find out which kind o= f=20 filesystems would be useful according to the filesystem size. maybe it can= =20 give out a warning: "If you use ext2 or ext3 it will take longer to format= =20 the filesystem the more huge the RAID system is.") "The RAID 5 system has been formatted with $1 properly. Now you will be=20 redirected to the Mount-Module in order to mount your RAID 5 system. Its=20 device name will be /dev/md0. Please indicate the mountpoint in the textbox= =20 and then click on $2". Well so far for the whitepaper ;-) Martin =2D-=20 Debian GNU/Linux http://www.debian.org/ SuSE Linux http://www.suse.de/ RedHat Linux http://www.redhat.com/ =46edora Project http://www.fedora.us/ |
From: Jamie C. <jca...@we...> - 2004-06-03 22:56:05
|
On Thu, 2004-06-03 at 20:00, Martin Mewes wrote: > Hi all, > > yesterday I installed my first Linux-RAID with Webmin with no problems. > Unfortunately I forgot to switch off the powersave-daemon so this night the > server went to sleep ;-) > > Ok, then - hard reset - deactivating powersave - RAID-Module > > Now I see that the RAID is being rebuilded and I can see the progress > everytime I click on browser's refresh. As this RAID is somewhat 350 GiB > heavy the progress is slow, but what I want to know is: > > Would it be hard to implement an automatic page refresh like it is in the > Mailbox-Module? Sure .. I should be able to sneak that into the 1.150 release. - Jamie |
From: Martin M. <mm...@me...> - 2004-06-03 21:23:52
|
###################################################################### History: -------- 03.06.2004 Webmin-Version 1.150 released as stable Usermin-Version 1.080 released as stable 28.05.2004 Webmin-Development-Version 1.149 released Usermin-Development-Version 1.079 released 26.04.2004 Virtualmin-Version 1.91 released as stable ###################################################################### Current Stable Release for Webmin is 1.150 http://prdownloads.sourceforge.net/sourceforge/webadmin/webmin-1.150.tar.gz http://prdownloads.sourceforge.net/webadmin/webmin-1.150-1.noarch.rpm http://webmin.mamemu.de/devel/tarballs/webmin-1.150-minimal.tar.gz Current Development Release for Webmin is 1.150 http://prdownloads.sourceforge.net/sourceforge/webadmin/webmin-1.150.tar.gz http://prdownloads.sourceforge.net/webadmin/webmin-1.150-1.noarch.rpm http://webmin.mamemu.de/devel/tarballs/webmin-1.150-minimal.tar.gz Current Stable Release for Usermin is 1.080 http://prdownloads.sourceforge.net/webadmin/usermin-1.080.tar.gz http://prdownloads.sourceforge.net/webadmin/usermin-1.080-1.noarch.rpm http://webmin.mamemu.de/devel/tarballs/usermin-1.080.tar.gz Current Development Release for Usermin is 1.080 http://prdownloads.sourceforge.net/webadmin/usermin-1.080.tar.gz http://prdownloads.sourceforge.net/webadmin/usermin-1.080-1.noarch.rpm http://webmin.mamemu.de/devel/tarballs/usermin-1.080.tar.gz Current Stable Release for VirtualMin is 1.91 http://webmin.mamemu.de/download/virtualmin/virtual-server-1.91.wbm.gz ###################################################################### If you are anoyed by these post you can filter this with procmail scanning for X-Webmin: update in the header. kind regards Martin Mewes |
From: Martin M. <mm...@me...> - 2004-06-03 10:00:44
|
Hi all, yesterday I installed my first Linux-RAID with Webmin with no problems. Unfortunately I forgot to switch off the powersave-daemon so this night = the server went to sleep ;-) Ok, then - hard reset - deactivating powersave - RAID-Module Now I see that the RAID is being rebuilded and I can see the progress everytime I click on browser's refresh. As this RAID is somewhat 350 GiB heavy the progress is slow, but what I want to know is: Would it be hard to implement an automatic page refresh like it is in the Mailbox-Module? bis dahin - kind regards Martin Mewes --=20 http://webmin.mamemu.de/ Official Webmin/Usermin Translation Co-Ordinator 2003/2004 Proud Forte Agent 2.0 Beta Tester |
From: Jamie C. <jca...@we...> - 2004-06-01 22:58:22
|
On Wed, 2004-06-02 at 01:16, Adam Kennedy wrote: > Not sure if it's widely known as existing or not, but the cluster-software > module works fairly well on Slackware boxes. I threw slackware-linux in the > proper place in module.info. It works ok for me =) Thanks for the information - I'm not sure why I didn't include Slackware support in the first place! - Jamie |
From: Jamie C. <jca...@we...> - 2004-06-01 22:58:18
|
On Wed, 2004-06-02 at 02:46, Jaldhar H. Vyas wrote: > On Tue, 1 Jun 2004, Jamie Cameron wrote: > > > I think the best solution here is for the Debian package of Webmin to > > always ensure that packages from apt are used when installing core > > modules, rather than normal .wbm files. This would mean modifying the > > CGIs that handle module and theme installation, to detect if the Debian > > package is in use and to refuse to install a module if an apt package > > for it exists. > > > > The code for installing a standard module and updating modules could > > also be modified to install with apt-get, or perhaps removed altogether. > > What do you think? > > > > Yes that is possible. But Martin explained why simply disabling the > ability to install is not something users would like. I wasn't thinking of totally disabling module installation, just preventing it for modules with have .deb packages (the core modules). > Debian policy declares /usr/local to be off-limits to .deb packages. This > is why I suggested two module roots. If packaged modules installed > into /usr/share webmin (which I handle now in my packages) while locally > installed modules installed into /usr/local/share/webmin, We could > guarantee that neither would stomp over the other. And the configuration > which currently goes into /etc/webmin could go into /usr/local/etc/webmin > Of course all four places would be configurable variables so a user of > the tarball could arrange them anyway he wanted. Having two root directories is neat, but may confuse some modules. A lot of them are written to assume that all module directories lie under the same root, and access files in other modules with paths like ../othermodule/somefile.pl . This could be fixed for the core modules, but may break third-party code .. I still think having one root directory is best, as long as there is no possibility of modules from .deb packages being overwritten, which seems to be the core problem here. - Jamie |
From: Jamie C. <jca...@we...> - 2004-06-01 22:58:15
|
On Wed, 2004-06-02 at 00:02, Martin Mewes wrote: > Hi Jamie, > > Jamie Cameron <jca...@we...> wrote: > > >On Tue, 2004-06-01 at 22:10, Jaldhar H. Vyas wrote: > >> A big problem I have as the Debian packages of webmin/usermin is dealing > >> with locally installed modules. The ability to install an updated WBM is > >> a good idea especially for the times when I fall behind in packaging but > >> it can also cause problems. The package management system doesn't know if > >> you're going behind its back. It can overwrite your stuff or not be aware > >> its installed. > > > >I think the best solution here is for the Debian package of Webmin to > >always ensure that packages from apt are used when installing core > >modules, rather than normal .wbm files. This would mean modifying the > >CGIs that handle module and theme installation, to detect if the Debian > >package is in use and to refuse to install a module if an apt package > >for it exists. > > > >The code for installing a standard module and updating modules could > >also be modified to install with apt-get, or perhaps removed altogether. > >What do you think? > > Bad catch :-( > If Webmin is installed with "apt-get webmin" and finally rejects > installations of wbm's this would break the freedom to install my modules > the way I want. What if a module does not exist as deb? > > I hope I did not missunderstand this part ;-) Don't worry, I wasn't suggesting removing .wbm support totally. Instead, I was thinking of forcing the use of .debs where they exist (for the 'core' modules like apache, sendmail and so on). So third-party .wbm files would still work fine.. > >> I wonder if it would be possible to do something like perl does for > >> modules. You can define installation spaces for core (comes with perl) > >> vendor (i.e. packaged by a distro) and site (for stuff you download > >> yoursef from CPAN.) Webmin would probably only need two tiers. How hard > >> would it be to have miniserv look for modules in two places? What else > >> would need to be changed? > > > >This could perhaps be done under miniserv, but it would break the > >support for running Webmin under Apache. So I think a better solution is > >to divide modules into two groups - 'core' and 'third-party', and ensure > >that only third-party modules are installed from .wbm files. > > Maybe Webmin can be modified to built a deb on the fly out of a wbm and > install that instead of the wbm? Interesting idea .. perhaps Jaldhar could comment on this one? - Jamie |
From: Jaldhar H. V. <ja...@de...> - 2004-06-01 16:47:37
|
On Tue, 1 Jun 2004, Jamie Cameron wrote: > I think the best solution here is for the Debian package of Webmin to > always ensure that packages from apt are used when installing core > modules, rather than normal .wbm files. This would mean modifying the > CGIs that handle module and theme installation, to detect if the Debian > package is in use and to refuse to install a module if an apt package > for it exists. > > The code for installing a standard module and updating modules could > also be modified to install with apt-get, or perhaps removed altogether. > What do you think? > Yes that is possible. But Martin explained why simply disabling the ability to install is not something users would like. Debian policy declares /usr/local to be off-limits to .deb packages. This is why I suggested two module roots. If packaged modules installed into /usr/share webmin (which I handle now in my packages) while locally installed modules installed into /usr/local/share/webmin, We could guarantee that neither would stomp over the other. And the configuration which currently goes into /etc/webmin could go into /usr/local/etc/webmin Of course all four places would be configurable variables so a user of the tarball could arrange them anyway he wanted. > This could perhaps be done under miniserv, but it would break the > support for running Webmin under Apache. Apache users could probably use mod_rewrite to make both module roots look like one. As it is they have to do some tweaking to get webmin working under Apache so it shouldn't be too burdensome. > So I think a better solution is > to divide modules into two groups - 'core' and 'third-party', and ensure > that only third-party modules are installed from .wbm files. > I still think my suggestion would be more flexible. -- Jaldhar H. Vyas <ja...@de...> La Salle Debain - http://www.braincells.com/debian/ |
From: Jaldhar H. V. <ja...@de...> - 2004-06-01 16:24:36
|
On Tue, 1 Jun 2004, Martin Mewes wrote: > Bad catch :-( > If Webmin is installed with "apt-get webmin" and finally rejects > installations of wbm's this would break the freedom to install my modules > the way I want. What if a module does not exist as deb? > ... > Maybe Webmin can be modified to built a deb on the fly out of a wbm and > install that instead of the wbm? In fact I already tried this. I briefly disabled the ability to install local modules and as you say users hated the idea. I also did a wbm 2 deb script which worked well -- except for the times when it didn't work at all. :-( One of these days dpkg is going to get the ability to add individual files into its database and then all our problems will be over. But that is a long way off. -- Jaldhar H. Vyas <ja...@de...> La Salle Debain - http://www.braincells.com/debian/ |
From: Adam K. <ake...@ni...> - 2004-06-01 15:16:05
|
Not sure if it's widely known as existing or not, but the cluster-software module works fairly well on Slackware boxes. I threw slackware-linux in the proper place in module.info. It works ok for me =) -- Northern Indiana ESC Adam Kennedy - ake...@ni... Linux Specialist / Network Administrator Phone: (574) 254-0111 x113 Toll Free: 800-326-5642 Fax: (574) 254-0148 |
From: Martin M. <mm...@me...> - 2004-06-01 14:02:51
|
Hi Jamie, Jamie Cameron <jca...@we...> wrote: >On Tue, 2004-06-01 at 22:10, Jaldhar H. Vyas wrote: >> A big problem I have as the Debian packages of webmin/usermin is = dealing >> with locally installed modules. The ability to install an updated WBM= is >> a good idea especially for the times when I fall behind in packaging = but >> it can also cause problems. The package management system doesn't = know if >> you're going behind its back. It can overwrite your stuff or not be = aware >> its installed. > >I think the best solution here is for the Debian package of Webmin to >always ensure that packages from apt are used when installing core >modules, rather than normal .wbm files. This would mean modifying the >CGIs that handle module and theme installation, to detect if the Debian >package is in use and to refuse to install a module if an apt package >for it exists. > >The code for installing a standard module and updating modules could >also be modified to install with apt-get, or perhaps removed altogether. >What do you think? Bad catch :-( If Webmin is installed with "apt-get webmin" and finally rejects installations of wbm's this would break the freedom to install my modules the way I want. What if a module does not exist as deb? I hope I did not missunderstand this part ;-) >> I wonder if it would be possible to do something like perl does for >> modules. You can define installation spaces for core (comes with = perl) >> vendor (i.e. packaged by a distro) and site (for stuff you download >> yoursef from CPAN.) Webmin would probably only need two tiers. How = hard >> would it be to have miniserv look for modules in two places? What = else >> would need to be changed? > >This could perhaps be done under miniserv, but it would break the >support for running Webmin under Apache. So I think a better solution is >to divide modules into two groups - 'core' and 'third-party', and ensure >that only third-party modules are installed from .wbm files. Maybe Webmin can be modified to built a deb on the fly out of a wbm and install that instead of the wbm? bis dahin - kind regards Martin Mewes --=20 http://webmin.mamemu.de/ Official Webmin/Usermin Translation Co-Ordinator 2003/2004 Proud Forte Agent 2.0 Beta Tester |
From: Jamie C. <jca...@we...> - 2004-06-01 13:25:33
|
On Tue, 2004-06-01 at 22:10, Jaldhar H. Vyas wrote: > A big problem I have as the Debian packages of webmin/usermin is dealing > with locally installed modules. The ability to install an updated WBM is > a good idea especially for the times when I fall behind in packaging but > it can also cause problems. The package management system doesn't know if > you're going behind its back. It can overwrite your stuff or not be aware > its installed. I think the best solution here is for the Debian package of Webmin to always ensure that packages from apt are used when installing core modules, rather than normal .wbm files. This would mean modifying the CGIs that handle module and theme installation, to detect if the Debian package is in use and to refuse to install a module if an apt package for it exists. The code for installing a standard module and updating modules could also be modified to install with apt-get, or perhaps removed altogether. What do you think? > I wonder if it would be possible to do something like perl does for > modules. You can define installation spaces for core (comes with perl) > vendor (i.e. packaged by a distro) and site (for stuff you download > yoursef from CPAN.) Webmin would probably only need two tiers. How hard > would it be to have miniserv look for modules in two places? What else > would need to be changed? This could perhaps be done under miniserv, but it would break the support for running Webmin under Apache. So I think a better solution is to divide modules into two groups - 'core' and 'third-party', and ensure that only third-party modules are installed from .wbm files. - Jamie |
From: Jaldhar H. V. <ja...@de...> - 2004-06-01 12:11:38
|
A big problem I have as the Debian packages of webmin/usermin is dealing with locally installed modules. The ability to install an updated WBM is a good idea especially for the times when I fall behind in packaging but it can also cause problems. The package management system doesn't know if you're going behind its back. It can overwrite your stuff or not be aware its installed. I wonder if it would be possible to do something like perl does for modules. You can define installation spaces for core (comes with perl) vendor (i.e. packaged by a distro) and site (for stuff you download yoursef from CPAN.) Webmin would probably only need two tiers. How hard would it be to have miniserv look for modules in two places? What else would need to be changed? -- Jaldhar H. Vyas <ja...@de...> La Salle Debain - http://www.braincells.com/debian/ |
From: <ait...@ya...> - 2004-06-01 10:07:45
|
Rebonjour lol merci je vient de resoudre le probleme Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Dialoguez en direct avec vos amis grâce à Yahoo! Messenger !Téléchargez Yahoo! Messenger sur http://fr.messenger.yahoo.com |
From: <ait...@ya...> - 2004-06-01 09:45:38
|
Bonjour j ai cree directement dans Webmin ( /usr/libexec/webmin),mon nouveau module qui contien les scriptes cgi ecritent en perl. maix quand je l execute via le navigateur web il m affiche bien les entetes mais au corps il met le message d erreur ( Accès refusé : l'utilisateur root n'est pas autorisé à utiliser le module ). et j aimerai bien savoir si j ai oublier de changer ou d ajouter une chose . merci c est un peu urgent. Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Dialoguez en direct avec vos amis grâce à Yahoo! Messenger !Téléchargez Yahoo! Messenger sur http://fr.messenger.yahoo.com |