Menu
▾
▴
webadmin-devel
|
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: 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 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: 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: 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: 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-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-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: Conny B. <ko...@ni...> - 2004-06-13 22:20:43
|
Jamie Cameron wrote:
>> 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.
This is an exiting front of development. In the meantime, here's how I
usually go about when installing webmin on a debian system:
1. Install package webmin (also pulls in webmin-core)
2. Set the two packages to "hold" to prevent further dpkg updates
3. Move /usr/share/webmin to /usr/share/webmin-deb
4. Create a symbolic link to match the dir used in the init.d script:
/usr/share/webmin -> /usr/share/webmin-deb
5. Go into "update webmin", pull down latest version
6. Update link from step #4 to point to the latest version:
/usr/share/webmin -> /usr/share/webmin-1.150
7. Restart miniserv (invoke-rc.d webmin restart)
Thereafter I can install/remove any modules I'like to via .wbm.
It saves me the initial setup, startscripts, plus comes with module
configs that I know would work with my current debian release
(whichever it might be).
//conny
|
|
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: 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: 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-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/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X