From: Jamie C. <jca...@we...> - 2001-11-30 12:19:58
|
Webmin version 0.89 is now available for download from http://www.webmin.com/webmin/ and mirror sites. New features in this version include : - Added QMail Server module, for those who prefer it to Sendmail. - Added Cluster Users and Groups module for adding and modifying users across multiple machines. - Fixed authentication problems effecting some Redhat versions (hopefully for good this time). - Many small bugfixes and new features. As always, send me any bug reports on feature suggestions for the next release! - Jamie |
From: Riemer P. <ri...@pa...> - 2001-11-30 12:39:15
|
On Fri, 30 Nov 2001, Jamie Cameron wrote: >Subject: Webmin version 0.91 released Yeah! >Webmin version 0.89 is now available for download Errr....? > - Fixed authentication problems effecting some Redhat > versions (hopefully for good this time). Never had those (on 6.1, 6.2, 7.0, 7.1 or 7.2) -- http://palstra.com |
From: Jamie C. <jca...@we...> - 2001-11-30 14:31:43
|
Jamie Cameron wrote: > > Webmin version 0.89 is now available for download from > http://www.webmin.com/webmin/ and mirror sites. New > features in this version include : > > - Added QMail Server module, for those who prefer it > to Sendmail. > > - Added Cluster Users and Groups module for adding > and modifying users across multiple machines. > > - Fixed authentication problems effecting some Redhat > versions (hopefully for good this time). > > - Many small bugfixes and new features. > > As always, send me any bug reports on feature suggestions > for the next release! > > - Jamie Of course, the version number above should read 0.91 .. that's what happens when you just copy and paste an old release email :) - Jamie |
From: Jamie C. <jca...@we...> - 2001-11-30 22:23:44
|
My mistake .. I changed the name of the RPM file used on the website, but didn't update the webmin code in older versions to use the new name! However, a symlink has fixed the problem, so try upgrading again now .. - Jamie Ralph Houben wrote: > > hello folks! > > erm, jamie? i havent posted to this list before > since i didn't have to cuz webmin does what > it is supposed to do for me till now, and i have > been using it for a long time now but erm, i saw > your mail about the upgrade, and impatient > as i am i went to: > > http://localhost:10000/webmin/edit_upgrade.cgi > > and clicked on upgrade from website: > > Failed to upgrade from www.webmin.com : Download failed : HTTP/1.0 > 404 Not Found > > can ya shed some enlightenment on this?... > > ralph houben > > Jamie Cameron wrote: > > >Jamie Cameron wrote: > > > >>Webmin version 0.89 is now available for download from > >>http://www.webmin.com/webmin/ and mirror sites. New > >>features in this version include : > >> > >> - Added QMail Server module, for those who prefer it > >> to Sendmail. > >> > >> - Added Cluster Users and Groups module for adding > >> and modifying users across multiple machines. > >> > >> - Fixed authentication problems effecting some Redhat > >> versions (hopefully for good this time). > >> > >> - Many small bugfixes and new features. > >> > >>As always, send me any bug reports on feature suggestions > >>for the next release! > >> > >> - Jamie > >> > > > >Of course, the version number above should read 0.91 .. > >that's what happens when you just copy and paste an old > >release email :) > > > > - Jamie |
From: Dennis <de...@et...> - 2001-11-30 19:37:14
|
Is there a way to find out what specific modules were changed? We do quite a bit of customization and its a big project to upgrade. Dennis At 07:42 AM 11/30/2001, Riemer Palstra wrote: >On Fri, 30 Nov 2001, Jamie Cameron wrote: > > >Subject: Webmin version 0.91 released > >Yeah! > > >Webmin version 0.89 is now available for download > >Errr....? > > > - Fixed authentication problems effecting some Redhat > > versions (hopefully for good this time). > >Never had those (on 6.1, 6.2, 7.0, 7.1 or 7.2) > >-- >http://palstra.com > > >- >Forwarded by the Webmin mailing list at web...@li... >To remove yourself from this list, go to >http://lists.sourceforge.net/lists/listinfo/webadmin-list |
From: alfred w. <ad...@mu...> - 2002-09-22 19:27:45
|
Jamie, which webmin do you recomment for xserve with OSX Server 10.2. is there any experience (workarounds etc.) to keep in mind when installing. greetings from berlin (today is the election of mr. stoiber or schr=F6der...) |
From: Jamie C. <jca...@we...> - 2002-09-22 22:44:20
|
alfred wippermann wrote: > Jamie, > > which webmin do you recomment for xserve with OSX Server 10.2. > > is there any experience (workarounds etc.) to keep in mind when > installing. > > greetings from berlin Webmin 1.000 will work fine on OSX 10.2 .. you just have to download and install the .tar.gz version. - Jamie |
From: alfred w. <ad...@mu...> - 2002-09-23 06:51:38
|
thank you jamie, we will follow your advice. hope everything will work fine alfred Jamie Cameron wrote: > alfred wippermann wrote: > > > Jamie, > > > > which webmin do you recomment for xserve with OSX Server 10.2. > > > > is there any experience (workarounds etc.) to keep in mind when > > installing. > > > > greetings from berlin > > Webmin 1.000 will work fine on OSX 10.2 .. you just have to download > and install the .tar.gz version. > > - Jamie > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > - > Forwarded by the Webmin mailing list at web...@li... > To remove yourself from this list, go to > http://lists.sourceforge.net/lists/listinfo/webadmin-list |
From: dale's l. a. <li...@be...> - 2002-09-23 07:02:30
|
Alfred, I expect to be around later today if you have any problems, give me a call at home :) Maybe I can make it to berlin later in the week to help you out. Dale On Monday, September 23, 2002, at 08:52 AM, alfred wippermann wrote: > thank you jamie, > > we will follow your advice. hope everything will work fine > > alfred > > Jamie Cameron wrote: > >> alfred wippermann wrote: >> >>> Jamie, >>> >>> which webmin do you recomment for xserve with OSX Server 10.2. >>> >>> is there any experience (workarounds etc.) to keep in mind when >>> installing. >>> >>> greetings from berlin >> >> Webmin 1.000 will work fine on OSX 10.2 .. you just have to download >> and install the .tar.gz version. >> >> - Jamie |
From: Norberto B. <nb...@ya...> - 2001-12-01 09:23:48
|
----- Original Message ----- From: "Jamie Cameron" <jca...@we...> | | - Added QMail Server module, for those who prefer it | to Sendmail. | And now you tell me... I've just installed Postfix 'cause 0.90 didn't have a module for QMail! :-) Regards, Norberto |
From: Joe C. <jo...@sw...> - 2001-12-01 20:32:09
|
I'd try: diff -uNr webmin-0.90 webmin-0.91 > changes.diff Or for specific modules: diff -uNr webmin-0.90/apache webmin-0.91 > apache-module-changes.diff Dennis wrote: > Is there a way to find out what specific modules were changed? We do > quite a bit of customization and its a big project to upgrade. > > Dennis > > At 07:42 AM 11/30/2001, Riemer Palstra wrote: > >> On Fri, 30 Nov 2001, Jamie Cameron wrote: >> >> >Subject: Webmin version 0.91 released >> >> Yeah! >> >> >Webmin version 0.89 is now available for download >> >> Errr....? >> >> > - Fixed authentication problems effecting some Redhat >> > versions (hopefully for good this time). >> >> Never had those (on 6.1, 6.2, 7.0, 7.1 or 7.2) >> >> -- >> http://palstra.com -- Joe Cooper <jo...@sw...> http://www.swelltech.com Web Caching Appliances and Support |
From: Dennis <de...@et...> - 2001-12-03 14:49:28
|
At 03:34 PM 12/01/2001, Joe Cooper wrote: >I'd try: > >diff -uNr webmin-0.90 webmin-0.91 > changes.diff I guess that I was asking if there is an "official" changes.diff available, so that we wouldnt have to load it and do it ourselves..... dennis |
From: Joe C. <jo...@sw...> - 2001-12-03 14:58:05
|
Not that I know of, though it is a pretty easy scripting job, I would think. Set it up to untar any two arbitrary Webmin versions into separate directories and then diff them. That's one of the nice things about CVS. Incremental diffs can be provided easily and automatically between any checked-in version of any file. But Webmin isn't developed in CVS...And I don't know that it needs to be since there is only one primary developer, and Jamie seems to plan to keep it that way for the foreseeable future (accepting any reasonable patches from us users without hassle of course). Rather than track such changes, I tend to write independent modules for the special functions we need...Then no modifications are needed as long as all of the function calls in other modules that we use keep the same interfaces. That's not always possible, I know...especially for major frontend changes (we use a custom theme, but it doesn't touch the interface drawing code--just adds all new icons, colors and Dennis wrote: > At 03:34 PM 12/01/2001, Joe Cooper wrote: > >> I'd try: >> >> diff -uNr webmin-0.90 webmin-0.91 > changes.diff > > > > I guess that I was asking if there is an "official" changes.diff > available, so that we wouldnt have to load it and do it ourselves..... > > dennis -- Joe Cooper <jo...@sw...> http://www.swelltech.com Web Caching Appliances and Support |
From: Fred B. <ba...@ae...> - 2001-12-03 15:53:53
|
--On Monday, December 03, 2001 09:00:15 AM -0600 Joe Cooper <jo...@sw...> wrote: > But Webmin isn't developed in CVS...And I don't know that it needs > to be since there is only one primary developer Ack! I can't believe that anyone would say such a thing! Version control is an essential programming methodology for any substantial project, regardless of the number of developers. If the code is going to stick around for more than a week, it should be under a version control system of some kind. It doesn't have to be CVS, just use something! In fact, my biggest complaint against Webmin is that it doesn't have some simple way to revert the configuration to earlier settings. I would think that RCS could be used for something like this. Just my $.02. ;-) Great software! Keep up the good work. Fred Bacon Aerodyne Research, Inc. |
From: Dennis <de...@et...> - 2001-12-03 20:29:25
|
At 10:00 AM 12/03/2001, you wrote: >Not that I know of, though it is a pretty easy scripting job, I would >think. Set it up to untar any two arbitrary Webmin versions into separate >directories and then diff them. > >That's one of the nice things about CVS. Incremental diffs can be >provided easily and automatically between any checked-in version of any >file. But Webmin isn't developed in CVS...And I don't know that it needs >to be since there is only one primary developer, and Jamie seems to plan >to keep it that way for the foreseeable future (accepting any reasonable >patches from us users without hassle of course). > >Rather than track such changes, I tend to write independent modules for >the special functions we need...Then no modifications are needed as long >as all of the function calls in other modules that we use keep the same >interfaces. That's not always possible, I know...especially for major >frontend changes (we use a custom theme, but it doesn't touch the >interface drawing code--just adds all new icons, colors and Most of our changes are cosmetic..ie we have our own tab structure and a lot of text changes..only a couple of modules have code changes such as we changed the network modules to display all installed devices whether they are active or not...but its a pain to have to redo all of the changes for a couple of things that we may care nothing about. I dont think that the number of developers or how the developer does his work is relevant. What is important is that the user base is being serviced adequately...and now that webmin is distributed with the BSD license it makes sense perhaps to rethink how upgrades are done considering that there may be a lot of companies using it, and that most of them will have made some changes. Frankly, I'd rather see each module have a revision, and some control over the compatibility with the main libraries, so that we can just grab a module if there is a useful change, rather than have to load the entire distribution once a month. It takes away from the modularity of the subsystem if there is a dependency on the version of "webmin"...a goal should be that all modules be totally independent..so that you can upgrade any of the pieces independently. All of our custom modules are written in C, so they are totally independent of the webmin version, which makes life a lot easier in terms of maintenance. Dennis |
From: Joe C. <jo...@sw...> - 2001-12-03 19:45:54
|
Fred Bacon wrote: > --On Monday, December 03, 2001 09:00:15 AM -0600 Joe Cooper > <jo...@sw...> wrote: > >> But Webmin isn't developed in CVS...And I don't know that it needs >> to be since there is only one primary developer > > > Ack! I can't believe that anyone would say such a thing! Version > control is an essential programming methodology for any substantial > project, regardless of the number of developers. If the code is going > to stick around for more than a week, it should be under a version > control system of some kind. It doesn't have to be CVS, just use > something! Every developer has their own methods. Jamie is one of the most productive programmers I've ever met, and I know a lot of programmers...so I sure as heck aint gonna tell him how to run his show. I bow to my betters in matters of opinion, and Jamie is certainly my better in programming perl. > In fact, my biggest complaint against Webmin is that it doesn't have > some simple way to revert the configuration to earlier settings. I > would think that RCS could be used for something like this. Just my > $.02. ;-) I remember hearing rumblings a couple months back that there were some unused functions in versions of Webmin that looked like latent version control features. I think you may get your wish before to long. Jamie hasn't talked about this, so no guarantees I guess, but I wouldn't be surprised if RCS support sneaks in at some not to distant release. -- Joe Cooper <jo...@sw...> http://www.swelltech.com Web Caching Appliances and Support |
From: Joe C. <jo...@sw...> - 2001-12-03 22:26:25
|
Dennis wrote: > At 10:00 AM 12/03/2001, you wrote: > >> Not that I know of, though it is a pretty easy scripting job, I would >> think. Set it up to untar any two arbitrary Webmin versions into >> separate directories and then diff them. >> >> That's one of the nice things about CVS. Incremental diffs can be >> provided easily and automatically between any checked-in version of >> any file. But Webmin isn't developed in CVS...And I don't know that >> it needs to be since there is only one primary developer, and Jamie >> seems to plan to keep it that way for the foreseeable future >> (accepting any reasonable patches from us users without hassle of >> course). >> >> Rather than track such changes, I tend to write independent modules >> for the special functions we need...Then no modifications are needed >> as long as all of the function calls in other modules that we use keep >> the same interfaces. That's not always possible, I know...especially >> for major frontend changes (we use a custom theme, but it doesn't >> touch the interface drawing code--just adds all new icons, colors and > > > Most of our changes are cosmetic..ie we have our own tab structure and a > lot of text changes..only a couple of modules have code changes such as > we changed the network modules to display all installed devices whether > they are active or not...but its a pain to have to redo all of the > changes for a couple of things that we may care nothing about. > > I dont think that the number of developers or how the developer does his > work is relevant. What is important is that the user base is being > serviced adequately...and now that webmin is distributed with the BSD > license it makes sense perhaps to rethink how upgrades are done > considering that there may be a lot of companies using it, and that most > of them will have made some changes. > > Frankly, I'd rather see each module have a revision, and some control > over the compatibility with the main libraries, so that we can just grab > a module if there is a useful change, rather than have to load the > entire distribution once a month. It takes away from the modularity of > the subsystem if there is a dependency on the version of "webmin"...a > goal should be that all modules be totally independent..so that you can > upgrade any of the pieces independently. All of our custom modules are > written in C, so they are totally independent of the webmin version, > which makes life a lot easier in terms of maintenance. I would concur that module revision numbers would be nice. Jamie, any chance we could get a MODULE_VERSION= variable in every standard module lib? Start all of them at some arbitrary number (as different as possible from the Webmin revision so no confusion results--like start at '100' or '1000' with the next Webmin release..marking all modules with it and incremement by one for every version that gets changed). And in the unlikely event of a function change that might break callers jump the revision up to the next 'major' number, like 200 or 2000. CVS does this automatically if you tell it to, but it's not worth switching to CVS just for revision numbers. I've never had any function call compatibility issues, but then I've only been using foreign calls for a few months. The primary web-lib.pl API has never changed in a destructive fashion as far as I know--at least not in recent times. Finally, on the interface issue...it's been discussed a bunch before, and I have to say that I don't think anything short of a template system with full interface control will fix this. A small subset of ZPT (Zope Page Templates) might do it, as long as the ZPT can handle or can be expanded to encompass the custom calls needed (ZPT is an arbitrarily chosen template system--a completely custom one would be fine as well, I'm just thinking that ZPT is already documented and pretty nicely designed and intended as a templating 'standard'). However, I don't know that I want to encourage Jamie to work on this sort of thing since there are still several cool things that are 'configurable' on a Unix machine that he could tackle instead. It would probably be a good project for some of us hangers on to tackle. Fine grained ACLs for most of the other (non-Apache) modules would also be a good area for us mere mortals to work on, with even less complexity. I reckon that's enough on the subject for me today. -- Joe Cooper <jo...@sw...> http://www.swelltech.com Web Caching Appliances and Support |
From: Jamie C. <jca...@we...> - 2001-12-04 09:28:41
|
Fred Bacon wrote: > > --On Monday, December 03, 2001 09:00:15 AM -0600 Joe Cooper > <jo...@sw...> wrote: > > > But Webmin isn't developed in CVS...And I don't know that it needs > > to be since there is only one primary developer > > Ack! I can't believe that anyone would say such a thing! Version control > is an essential programming methodology for any substantial project, > regardless of the number of developers. If the code is going to stick > around for more than a week, it should be under a version control system of > some kind. It doesn't have to be CVS, just use something! I once tried to move webmin into sourceforge's CVS server, but couldn't work out how to add symbolic links (which there are several of in the code) to CVS. Has anyone ever managed to do that? - Jamie |
From: Jamie C. <jca...@we...> - 2001-12-04 12:36:32
|
Joe Cooper wrote: > > Dennis wrote: > > > At 10:00 AM 12/03/2001, you wrote: > > > >> Not that I know of, though it is a pretty easy scripting job, I would > >> think. Set it up to untar any two arbitrary Webmin versions into > >> separate directories and then diff them. > >> > >> That's one of the nice things about CVS. Incremental diffs can be > >> provided easily and automatically between any checked-in version of > >> any file. But Webmin isn't developed in CVS...And I don't know that > >> it needs to be since there is only one primary developer, and Jamie > >> seems to plan to keep it that way for the foreseeable future > >> (accepting any reasonable patches from us users without hassle of > >> course). > >> > >> Rather than track such changes, I tend to write independent modules > >> for the special functions we need...Then no modifications are needed > >> as long as all of the function calls in other modules that we use keep > >> the same interfaces. That's not always possible, I know...especially > >> for major frontend changes (we use a custom theme, but it doesn't > >> touch the interface drawing code--just adds all new icons, colors and > > > > > > Most of our changes are cosmetic..ie we have our own tab structure and a > > lot of text changes..only a couple of modules have code changes such as > > we changed the network modules to display all installed devices whether > > they are active or not...but its a pain to have to redo all of the > > changes for a couple of things that we may care nothing about. > > > > I dont think that the number of developers or how the developer does his > > work is relevant. What is important is that the user base is being > > serviced adequately...and now that webmin is distributed with the BSD > > license it makes sense perhaps to rethink how upgrades are done > > considering that there may be a lot of companies using it, and that most > > of them will have made some changes. > > > > Frankly, I'd rather see each module have a revision, and some control > > over the compatibility with the main libraries, so that we can just grab > > a module if there is a useful change, rather than have to load the > > entire distribution once a month. It takes away from the modularity of > > the subsystem if there is a dependency on the version of "webmin"...a > > goal should be that all modules be totally independent..so that you can > > upgrade any of the pieces independently. All of our custom modules are > > written in C, so they are totally independent of the webmin version, > > which makes life a lot easier in terms of maintenance. > > I would concur that module revision numbers would be nice. Jamie, any > chance we could get a MODULE_VERSION= variable in every standard module > lib? Start all of them at some arbitrary number (as different as > possible from the Webmin revision so no confusion results--like start at > '100' or '1000' with the next Webmin release..marking all modules with > it and incremement by one for every version that gets changed). And in > the unlikely event of a function change that might break callers jump > the revision up to the next 'major' number, like 200 or 2000. CVS does > this automatically if you tell it to, but it's not worth switching to > CVS just for revision numbers. > > I've never had any function call compatibility issues, but then I've > only been using foreign calls for a few months. The primary web-lib.pl > API has never changed in a destructive fashion as far as I know--at > least not in recent times. The main API in web-lib.pl does change fairly often, though always in a backwards compatible way, and core modules in new releases usually make use of those new API changes. This means that releasing modules that are compatible with older versions of webmin so that people can do selective upgrades would not generally be possible, at least not until the core webmin API settles down. And I don't see any easy way to get around this problem, unless the core API itself is made into a module that can be selectively upgraded .. - Jamie |
From: Dennis <de...@et...> - 2001-12-05 01:30:38
|
>[heavy snippage..] >The main API in web-lib.pl does change fairly often, though always in >a backwards compatible way, and core modules in new releases usually make >use of those new API changes. This means that releasing modules that are >compatible with older versions of webmin so that people can do selective >upgrades would not generally be possible, at least not until the core >webmin API settles down. And I don't see any easy way to get around >this problem, unless the core API itself is made into a module that >can be selectively upgraded .. That way to do it is to make a list of all of the things that are dependent, and then figure out a way to make them independent. Theres no reason that the display can't be completely independent (in a the same way that the first tab level works), and authentication calls can certainly be made generic so they dont need to change. In the long run it saves a lot of time (well worth the effort to do it in the first place), as you dont have to update and verify every module every time you want to do a release. We have a product that we support both linux and Freebsd, and in the beginning to port it over was a big project and i grumbled about doing the work to make the interfaces generic. Now, I copy 2 files and recompile and its done. Dennis |