webadmin-devel — The webmin development mailing list

Re: [webmin-devel] Public CVS/Subversion?

[Paul G. <pa...@ge...>]

Jamie Cameron wrote:
> On 26/Jun/2007 16:38 Paul Gear wrote ..
>> Hi all,
>>
>> I'm trying to hack on the Webmin Shorewall module, which seems to need=

>> a
>> bit of updating, and i'm trying to locate the current CVS/Subversion
>> repository.  I found one at sourceforge.net, but it seems a few years
>> out of date.  Is there a current public repository?  Should i be
>> downloading the devel tgz snapshots instead?
>=20
> Hi Paul,
>=20
> There is an SVN repository, but it is not publicly available yet.
> However, if you want to contribute, email me your preferred login and
> password and I will add an account for you so that you can access it.

OK - thanks.  We'll leave the account until i've got something useful to
contribute...  :-)

--=20
Paul
<http://paulgear.webhop.net>
--
Did you know?  Most email-borne viruses use a false sender address, so
you cannot track down the sender using that address.  Instead, keep your
virus scanning software up-to-date and just delete any suspicious emails
you receive.

Re: [webmin-devel] Public CVS/Subversion?

[Jamie C. <jca...@we...>]

On 26/Jun/2007 16:38 Paul Gear wrote ..
> Hi all,
> 
> I'm trying to hack on the Webmin Shorewall module, which seems to need
> a
> bit of updating, and i'm trying to locate the current CVS/Subversion
> repository.  I found one at sourceforge.net, but it seems a few years
> out of date.  Is there a current public repository?  Should i be
> downloading the devel tgz snapshots instead?

Hi Paul,

There is an SVN repository, but it is not publicly available yet.
However, if you want to contribute, email me your preferred login and
password and I will add an account for you so that you can access it.

 - Jamie

Re: [webmin-devel] Public CVS/Subversion?

[matt w. <wes...@gm...>]

Hey Paul,  I don't know much about the shorewall module besides using it a
bit, I would probably start with the tar.gz for your source and with google
code your a few clicks from your own personal repository for it.  If you
need any help on the shorewall module just let me know.

-Matt

[webmin-devel] Public CVS/Subversion?

[Paul G. <pa...@ge...>]

Hi all,

I'm trying to hack on the Webmin Shorewall module, which seems to need a
bit of updating, and i'm trying to locate the current CVS/Subversion
repository.  I found one at sourceforge.net, but it seems a few years
out of date.  Is there a current public repository?  Should i be
downloading the devel tgz snapshots instead?

Thanks,
Paul
<http://paulgear.webhop.net>
--
Did you know?  Email viruses spread using addresses they find on the
host computer.  You can help to reduce the spread of these viruses by
using Bcc: instead of To: on mass mailings, or using mailing list
software such as mailman (http://www.list.org/) instead.

[webmin-devel] my email

[Jason W. <wan...@ho...>]

d2FuZ3FpbmdwZWlAaG90bWFpbC5jb20=

[webmin-devel] Looking for commercial Webmin module developers

[Jamie C. <jca...@we...>]

Hi Webmin module hackers,

Since I get more requests for custom module development that I can
handle, I am putting together a page listing developers who are 
available for hire. If you are interested in being listed, please
email at dev...@we... with your name and areas of expertise,
and I'll be happy to add you to the list..

Hopefully this way you can make some money doing custom development,
and I can tell people who are looking for Webmin experts where to go :)

 - Jamie

[webmin-devel] Sunshine Technology Solutions, LLC

[<ra...@su...>]

Hi Everyone,

     I would like to introduce myself to the list. My name is Ravi Gehlot
and I have been an user of Webmin/Usermin and Virtualmin for about 2
years now. My web-hosting business is on webmin technology and it
works perfectly thanks to all of you that contributed to the project
and to the creator Jamie Cameron himself. I used to be on the list
but got out and now I am back. If any of you have any questions feel
free to address me either on this list or over e-mail to
in...@su...

Thanks,
Ravi.


---------------------------------------
Sunshine Technology Solutions, LLC
http://www.sunshinetechsolutions.com/
ra...@su...
---------------------------------------

Re: [webmin-devel] Webmin 1.320 file upload improvements question

[Chris M. <Chr...@en...>]

Well I slapped something together to prove to myself that some solution
could be worked out. Nothing I'd show anyone as is. :-)
 
I think the only way to deal with this situation is to write the file out
within the function, or possibly pass the file handle back to the
application and create a utility function to read the file handle for us.
The boundary checking could be in the read funct. The later might be to
complex for webmin lib, it would require secondary usage explaination and I
don't think it fits into the single function call spirit of the existing lib
functs.
 
Also, I want to try and utilize sysread to control STDIN reading if
possible. The only catch is boundary testing, but since the CONTENT_TYPE
boundary is defined early, we know the length, so something could be worked
out.
 
Thanks.
 
- Chris

-----Original Message-----
From: web...@li...
[mailto:web...@li...] On Behalf Of Jamie
Cameron
Sent: Wednesday, January 31, 2007 8:20 PM
To: Webmin development list
Subject: Re: [webmin-devel] Webmin 1.320 file upload improvements question


On 31/Jan/2007 16:26 Chris Mckenzie wrote .. 

Thanks for the pointer Jamie. 

So I funked around with my own version of ReadParseMime() and found that it
was quite easy to get my own version going. The attached file read/write
needed to be handled in the ReadParseMime() funct.

In web-lib-funcs.pl, around line 392, there's a $in{$name} concat of each
line read from the posted file. Is it because of the CONTENT_TYPE bounrdy
checking? This could probably be worked around. Anyways, it seems to be the
culprit. Once the concatination wasn't factored in, memory usage was
hovering around 5.8%.


Yes, it needs to check for the boundary on each line. 
I'd be intersted to see your code change that reduced memory use .. I didn't
see anything attached to your posting.


I could speculate that the <STDIN> read used is reading in browser sent
blocks of data, and isn't controlled from the function. If a sysread from
<STDIN> was used, we could probably control the size of data read. I don't
necessarily like that 5.8% number, I'm not sure where the size block size is
determined. (based on something in the file/data that the Perl read decided
was a read line, or something the browser blocked itself)


A read from stdin will just get a single line at a time, which shouldn't be
too large.


The only way I can see to really reduce memory use is for the caller of
ReadParseMime to specify a file that should be written to for a particular
named input. That way a large upload could be saved directly to disk on the
server..


 - Jamie


Please let me know what you think, though I'll probably write my own version
of ReadParseMime(). You're more than welcome to the result, but I have a
less Perl style of coding, so you'd probably end up re-writing yourself
anyways.

I really like the way you've used callback functions, it's going to factor
into my upload progress. 

Thanks! 

- Chris 
-----Original Message----- 
From: web...@li...
[mailto:web...@li...] On Behalf Of Jamie
Cameron

Sent: Wednesday, January 31, 2007 6:30 PM 
To: Webmin development list 
Subject: Re: [webmin-devel] Webmin 1.320 file upload improvements question 


On 31/Jan/2007 14:33 Chris Mckenzie wrote .. 
Hi all. 
Long time webmin tinkerer, short time webamin-devel list troller. 
I had a question regarding the the improved file upload module and progress
bar window. 
* Improved handling of large file uploads so that they are no longer read
into memory by Webmin webserver. Also added a progress bar window for
tracking uploads. 

Firstly, my tests have shown that when attempting a file upload to miniserv,
the main miniserv process maynot gobble up memory for the download but the
spawned CGI that's being posted to does.

Yes, that is still unfortunately true - when using the default ReadParseMime
function for reading uploaded files, the entire content is read into memory.

I wrote a quick test to see if the fix would be suitable for a module I'm
looking at doing. (large file upload) It starts with a simple form:

<form method="POST" action="/test/handleUpload.cgi"
enctype="multipart/form-data"> 
  <input type="file" name="file" id="file" size="20"> 
</form> 
My handleUpload.cgi is pretty straightforward too: 
&ReadParseMime(); 
... 
    my $fh = new IO::File ">$write_file"; 
    if(defined($fh)) { 
      binmode $fh; 
      print $fh $in{'file'}; 
    } 
    $fh->close(); 
... 
The only way to avoid comsuming memory like this would be to write your own
replacement for ReadParseMime to write data directly to a file as it is read
by the CGI. I haven't done this yet, but it would be at least theoretically
possible now that the miniserv.pl process doesn't read the whole upload into
memory too :-)

 - Jamie 

Re: [webmin-devel] Webmin 1.320 file upload improvements question

[Jamie C. <jca...@we...>]

On 31/Jan/2007 16:26 Chris Mckenzie wrote ..
<blockquote type=3D"cite">


<p><font size=3D"2">Thanks for the pointer Jamie.</font>
</p>

<p><font size=3D"2">So I funked around with my own version of ReadParseMime() and found that it was quite easy to get my own version going. The attached file read/write needed to be handled in the ReadParseMime() funct.</font></p>

<p><font size=3D"2">In web-lib-funcs.pl, around line 392, there's a $in{$name} concat of each line read from the posted file. Is it because of the CONTENT_TYPE bounrdy checking? This could probably be worked around. Anyways, it seems to be the culprit. Once the concatination wasn't factored in, memory usage was hovering around 5.8%.<br /></font></p></blockquote>Yes, it needs to check for the boundary on each line. <br />I'd be intersted to see your code change that reduced memory use .. I didn't see anything attached to your posting.<br /><blockquote type=3D"cite">

<p><font size=3D"2">I could speculate that the &lt;STDIN&gt; read used is reading in browser sent blocks of data, and isn't controlled from the function. If a sysread from &lt;STDIN&gt; was used, we could probably control the size of data read. I don't necessarily like that 5.8% number, I'm not sure where the size block size is determined. (based on something in the file/data that the Perl read decided was a read line, or something the browser blocked itself)<br /></font></p></blockquote>A read from stdin will just get a single line at a time, which shouldn't be too large.<br /><p>The only way I can see to really reduce memory use is for the caller of ReadParseMime to specify a file that should be written to for a particular named input. That way a large upload could be saved directly to disk on the server..<br /></p><p>=A0- Jamie<br /></p><blockquote type=3D"cite">

<p><font size=3D"2">Please let me know what you think, though I'll probably write my own version of ReadParseMime(). You're more than welcome to the result, but I have a less Perl style of coding, so you'd probably end up re-writing yourself anyways.</font></p>

<p><font size=3D"2">I really like the way you've used callback functions, it's going to factor into my upload progress.</font>
</p>

<p><font size=3D"2">Thanks!</font>
</p>

<p><font size=3D"2">- Chris</font>
<br /><font size=3D"2">-----Original Message-----</font>
<br /><font size=3D"2">From: web...@li... [<a href=3D"reply_mail.cgi?new=3D1&to=3Dwebadmin%2Ddevel%2Dbounces%40lists%2Esourceforge%2Enet">mailto:web...@li...</a>] On Behalf Of Jamie Cameron</font></p>

<p><font size=3D"2">Sent: Wednesday, January 31, 2007 6:30 PM</font>
<br /><font size=3D"2">To: Webmin development list</font>
<br /><font size=3D"2">Subject: Re: [webmin-devel] Webmin 1.320 file upload improvements question</font>
</p>
<br />

<p><font size=3D"2">On 31/Jan/2007 14:33 Chris Mckenzie wrote .. </font>
<br /><font size=3D"2">Hi all. </font>
<br /><font size=3D"2">Long time webmin tinkerer, short time webamin-devel list troller. </font>
<br /><font size=3D"2">I had a question regarding the the improved file upload module and progress bar window. </font>
<br /><font size=3D"2">* Improved handling of large file uploads so that they are no longer read into memory by Webmin webserver. Also added a progress bar window for tracking uploads. </font></p>

<p><font size=3D"2">Firstly, my tests have shown that when attempting a file upload to miniserv, the main miniserv process maynot gobble up memory for the download but the spawned CGI that's being posted to does.</font></p>

<p><font size=3D"2">Yes, that is still unfortunately true - when using the default ReadParseMime function for reading uploaded files, the entire content is read into memory.</font></p>

<p><font size=3D"2">I wrote a quick test to see if the fix would be suitable for a module I'm looking at doing. (large file upload) It starts with a simple form:</font></p>

<p><font size=3D"2">&lt;form method=3D&quot;POST&quot; action=3D&quot;/test/handleUpload.cgi&quot; enctype=3D&quot;multipart/form-data&quot;&gt; </font>
<br /><font size=3D"2">=A0 &lt;input type=3D&quot;file&quot; name=3D&quot;file&quot; id=3D&quot;file&quot; size=3D&quot;20&quot;&gt; </font>
<br /><font size=3D"2">&lt;/form&gt; </font>
<br /><font size=3D"2">My handleUpload.cgi is pretty straightforward too: </font>
<br /><font size=3D"2">&amp;ReadParseMime(); </font>
<br /><font size=3D"2">... </font>
<br /><font size=3D"2">=A0=A0=A0 my $fh =3D new IO::File &quot;&gt;$write_file&quot;; </font>
<br /><font size=3D"2">=A0=A0=A0 if(defined($fh)) { </font>
<br /><font size=3D"2">=A0=A0=A0=A0=A0 binmode $fh; </font>
<br /><font size=3D"2">=A0=A0=A0=A0=A0 print $fh $in{'file'}; </font>
<br /><font size=3D"2">=A0=A0=A0 } </font>
<br /><font size=3D"2">=A0=A0=A0 $fh-&gt;close(); </font>
<br /><font size=3D"2">...</font>
<br /><font size=3D"2">The only way to avoid comsuming memory like this would be to write your own replacement for ReadParseMime to write data directly to a file as it is read by the CGI. I haven't done this yet, but it would be at least theoretically possible now that the miniserv.pl process doesn't read the whole upload into memory too :-)</font></p>

<p><font size=3D"2">=A0- Jamie</font>
</p>

</blockquote><br />

Re: [webmin-devel] Webmin 1.320 file upload improvements question

[Chris M. <Chr...@en...>]

Thanks for the pointer Jamie.

So I funked around with my own version of ReadParseMime() and found that it
was quite easy to get my own version going. The attached file read/write
needed to be handled in the ReadParseMime() funct.

In web-lib-funcs.pl, around line 392, there's a $in{$name} concat of each
line read from the posted file. Is it because of the CONTENT_TYPE bounrdy
checking? This could probably be worked around. Anyways, it seems to be the
culprit. Once the concatination wasn't factored in, memory usage was
hovering around 5.8%.

I could speculate that the <STDIN> read used is reading in browser sent
blocks of data, and isn't controlled from the function. If a sysread from
<STDIN> was used, we could probably control the size of data read. I don't
necessarily like that 5.8% number, I'm not sure where the size block size is
determined. (based on something in the file/data that the Perl read decided
was a read line, or something the browser blocked itself)

Please let me know what you think, though I'll probably write my own version
of ReadParseMime(). You're more than welcome to the result, but I have a
less Perl style of coding, so you'd probably end up re-writing yourself
anyways.

I really like the way you've used callback functions, it's going to factor
into my upload progress.

Thanks!

- Chris
-----Original Message-----
From: web...@li...
[mailto:web...@li...] On Behalf Of Jamie
Cameron
Sent: Wednesday, January 31, 2007 6:30 PM
To: Webmin development list
Subject: Re: [webmin-devel] Webmin 1.320 file upload improvements question


On 31/Jan/2007 14:33 Chris Mckenzie wrote .. 
Hi all. 
Long time webmin tinkerer, short time webamin-devel list troller. 
I had a question regarding the the improved file upload module and progress
bar window. 
* Improved handling of large file uploads so that they are no longer read
into memory by Webmin webserver. Also added a progress bar window for
tracking uploads. 
Firstly, my tests have shown that when attempting a file upload to miniserv,
the main miniserv process maynot gobble up memory for the download but the
spawned CGI that's being posted to does.

Yes, that is still unfortunately true - when using the default ReadParseMime
function for reading uploaded files, the entire content is read into memory.

I wrote a quick test to see if the fix would be suitable for a module I'm
looking at doing. (large file upload) It starts with a simple form:
<form method="POST" action="/test/handleUpload.cgi"
enctype="multipart/form-data"> 
  <input type="file" name="file" id="file" size="20"> 
</form> 
My handleUpload.cgi is pretty straightforward too: 
&ReadParseMime(); 
... 
    my $fh = new IO::File ">$write_file"; 
    if(defined($fh)) { 
      binmode $fh; 
      print $fh $in{'file'}; 
    } 
    $fh->close(); 
...
The only way to avoid comsuming memory like this would be to write your own
replacement for ReadParseMime to write data directly to a file as it is read
by the CGI. I haven't done this yet, but it would be at least theoretically
possible now that the miniserv.pl process doesn't read the whole upload into
memory too :-)
 - Jamie

Re: [webmin-devel] Webmin 1.320 file upload improvements question

[Jamie C. <jca...@we...>]

On 31/Jan/2007 14:33 Chris Mckenzie wrote ..
<blockquote type=3D"cite">


<p><font size=3D"2">Hi all.</font>
</p>

<p><font size=3D"2">Long time webmin tinkerer, short time webamin-devel list troller.</font>
</p>

<p><font size=3D"2">I had a question regarding the the improved file upload module and progress bar window.</font>
</p>

<p><font size=3D"2">* Improved handling of large file uploads so that they are no longer read into memory by Webmin webserver. Also added a progress bar window for tracking uploads. </font></p>

<p><font size=3D"2">Firstly, my tests have shown that when attempting a file upload to miniserv, the main miniserv process maynot gobble up memory for the download but the spawned CGI that's being posted to does.<br /></font></p></blockquote>Yes, that is still unfortunately true - when using the default ReadParseMime function for reading uploaded files, the entire content is read into memory.<br /><blockquote type=3D"cite">

<p><font size=3D"2">I wrote a quick test to see if the fix would be suitable for a module I'm looking at doing. (large file upload) It starts with a simple form:</font></p>

<p><font size=3D"2">&lt;form method=3D&quot;POST&quot; action=3D&quot;/test/handleUpload.cgi&quot; enctype=3D&quot;multipart/form-data&quot;&gt;</font>
<br /><font size=3D"2">=A0 &lt;input type=3D&quot;file&quot; name=3D&quot;file&quot; id=3D&quot;file&quot; size=3D&quot;20&quot;&gt;</font>
<br /><font size=3D"2">&lt;/form&gt;</font>
</p>

<p><font size=3D"2">My handleUpload.cgi is pretty straightforward too:</font>
</p>

<p><font size=3D"2">&amp;ReadParseMime();</font>
<br /><font size=3D"2">...</font>
<br /><font size=3D"2">=A0=A0=A0 my $fh =3D new IO::File &quot;&gt;$write_file&quot;;</font>
<br /><font size=3D"2">=A0=A0=A0 if(defined($fh)) {</font>
<br /><font size=3D"2">=A0=A0=A0=A0=A0 binmode $fh;</font>
<br /><font size=3D"2">=A0=A0=A0=A0=A0 print $fh $in{'file'};</font>
<br /><font size=3D"2">=A0=A0=A0 }</font>
<br /><font size=3D"2">=A0=A0=A0 $fh-&gt;close();</font>
<br /><font size=3D"2">...</font></p></blockquote><p><font size=3D"2">The only way to avoid comsuming memory like this would be to write your own replacement for ReadParseMime to write data directly to a file as it is read by the CGI. I haven't done this yet, but it would be at least theoretically possible now that the miniserv.pl process doesn't read the whole upload into memory too :-)</font></p><p><font size=3D"2">=A0- Jamie</font></p><br />

[webmin-devel] Webmin 1.320 file upload improvements question

[Chris M. <Chr...@en...>]

Hi all.

Long time webmin tinkerer, short time webamin-devel list troller.

I had a question regarding the the improved file upload module and progress
bar window.

* Improved handling of large file uploads so that they are no longer read
into memory by Webmin webserver. Also added a progress bar window for
tracking uploads. 

Firstly, my tests have shown that when attempting a file upload to miniserv,
the main miniserv process maynot gobble up memory for the download but the
spawned CGI that's being posted to does.

I wrote a quick test to see if the fix would be suitable for a module I'm
looking at doing. (large file upload) It starts with a simple form:

<form method="POST" action="/test/handleUpload.cgi"
enctype="multipart/form-data">
  <input type="file" name="file" id="file" size="20">
</form>

My handleUpload.cgi is pretty straightforward too:

&ReadParseMime();
...
    my $fh = new IO::File ">$write_file";
    if(defined($fh)) {
      binmode $fh;
      print $fh $in{'file'};
    }
    $fh->close();
...

This is the approach taken by Tim Neimueller
(http://www.niemueller.de/webmin/modules/upload/). I assumed the fix was
either transparent to the cgi module using this accepted method, or there's
some newer/different usage I need to use.

I really hope the fix isn't the applet solution found in the new File
module. That's cheating in my book. :-) Though I understand it helped
facilitate the progress bar capability.

If I can properly arrange for the file upload to not consume tons of memory,
I plan to design a progress bar with an IFRAME form post and Ajax. (which
I'll share if I ever get it working)


Here's my top output for a 1.2gig upload. The 1st process is miniserv, while
the 2nd is my handleUpload.cgi. Note the large SIZE and %MEM.

 17:20:26  up 6 days,  7:56,  3 users,  load average: 2.42, 1.97, 1.29
2 processes: 1 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
           total    0.3%    0.0%   15.4%  34.7%     1.3%   48.0%    0.0%
Mem:   382644k av,  378308k used,    4336k free,       0k shrd,    3304k
buff
                    280172k actv,   51884k in_d,    4868k in_c
Swap: 10241396k av, 1494184k used, 8747212k free                   40336k
cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
22768 root      15   0  5056 1020   652 D     0.0  0.2   0:00   0
miniserv.pl
25332 root      16   0 1181M 254M   420 R    10.9 68.0   8:32   0
miniserv.pl


Any ideas?

Thanks!

- Chris

Re: [webmin-devel] Bug? After deleting user access denied

[Jamie C. <jca...@we...>]

On 23/Dec/2006 16:36 Thomas Ohms wrote ..
> Am Samstag, 23. Dezember 2006 17:30 schrieb Jamie Cameron:
> > Hi Thomas,
> > This sounds like a Webmin bug, although not one that I've heard of before.
> > When this happens, what does the file /etc/webmin/webmin.acl contain?
> > That is the one that determines who has access to which modules..
> >
> >  - Jamie
> 
> Hi Jamie,
> 
> thanks for answering! Well first to answer your question: the file webmin.acl
> isn't changed. The only file in folder is this ".wh.webmin.acl" thing.

Is .wh.webmin actually the name of a user on your system? If not, that .acl
file would never be used. .

> But now I've found out something even more weird. I wanted to reproduce
> this error with another username and nothing happend. I still got access to
> all modules.
> So I've looked deeper and recognized it's only one user who's making trouble:
> I used Virtualmin to import existing vServer. For this (as far as I can
> remember) a Webmin and Unix user was created, too. At least the system
> put  something inside the "Name"-field similar to "Imported domain 
> host.domain.tld".
> Any idea how to fix this? Might it be worth a bug report?

Is there anything odd about this user, such as a strange username?
If definately sounds worth a bug report, although it may not be solvable without
logging into your system myself..

 - Jamie

Re: [webmin-devel] Bug? After deleting user access denied

[Thomas O. <mai...@oh...>]

Am Samstag, 23. Dezember 2006 17:30 schrieb Jamie Cameron:
> Hi Thomas,
> This sounds like a Webmin bug, although not one that I've heard of before.
> When this happens, what does the file /etc/webmin/webmin.acl contain? That
> is the one that determines who has access to which modules..
>
>  - Jamie

Hi Jamie,

thanks for answering! Well first to answer your question: the file webmin.acl 
isn't changed. The only file in folder is this ".wh.webmin.acl" thing.
But now I've found out something even more weird. I wanted to reproduce this 
error with another username and nothing happend. I still got access to all 
modules.
So I've looked deeper and recognized it's only one user who's making trouble:
I used Virtualmin to import existing vServer. For this (as far as I can 
remember) a Webmin and Unix user was created, too. At least the system put 
something inside the "Name"-field similar to "Imported domain 
host.domain.tld".
Any idea how to fix this? Might it be worth a bug report?

Greets and happy holidays
Thomas

Re: [webmin-devel] Bug? After deleting user access denied

[Jamie C. <jca...@we...>]

On 23/Dec/2006 01:39 Thomas Ohms wrote ..
> Hi everyone,
> 
> new to this list I will report a constantly error I can reproduce:
> 
> Problem: 
> As soon as an user gets deleted and I like to switch back to the previous
> module, an error occures saying I wouldn't have access to any module within
> Webmin. Login itself is fine.
> 
> Logs:
> Nothing strange can be seen in miniserv.error, miniserv.log and webmin.log
> 
> StackTrace:
> 	File 	Line 	Function
> 	../web-lib-funcs.pl 	2453 	main::error
> 	./user-lib.pl 	5 	main::init_config
> 	/usr/share/webmin/webmin-1.310/useradmin/index.cgi 	3 	(eval)
> 	(eval 16) 	5 	(eval)
> 	/usr/share/webmin/webmin-1.310/miniserv.pl 	1855 	(eval)
> 	/usr/share/webmin/webmin-1.310/miniserv.pl 	636 	miniserv::handle_request
> 
> Files:
> The error must have to do with on or all files of miniserv.users, 
> miniserv.conf, config, webmin.groups. Allthough I can see no change to
> the 
> original except the deleted user.
> 
> Further more:
> I have recognized that after the action there's an empty file 
> called ".wh.webmin.acl" with executing!! rights. What is this supposed
> to be?
> 
> Solution:
> Meanwhile the only solutin is to delete this file (.wh.webmin.acl) manually.
> What is this file about? Why is it blocking my access to modules, allthough
> it's empty? How can this be fixed?

Hi Thomas,
This sounds like a Webmin bug, although not one that I've heard of before.
When this happens, what does the file /etc/webmin/webmin.acl contain? That
is the one that determines who has access to which modules..

 - Jamie

[webmin-devel] Bug? After deleting user access denied

[Thomas O. <mai...@oh...>]

Hi everyone,

new to this list I will report a constantly error I can reproduce:

Problem:=20
As soon as an user gets deleted and I like to switch back to the previous=20
module, an error occures saying I wouldn't have access to any module within=
=20
Webmin. Login itself is fine.

Logs:
Nothing strange can be seen in miniserv.error, miniserv.log and webmin.log

StackTrace:
	File 	Line 	Function
	../web-lib-funcs.pl 	2453 	main::error
	./user-lib.pl 	5 	main::init_config
	/usr/share/webmin/webmin-1.310/useradmin/index.cgi 	3 	(eval)
	(eval 16) 	5 	(eval)
	/usr/share/webmin/webmin-1.310/miniserv.pl 	1855 	(eval)
	/usr/share/webmin/webmin-1.310/miniserv.pl 	636 	miniserv::handle_request

=46iles:
The error must have to do with on or all files of miniserv.users,=20
miniserv.conf, config, webmin.groups. Allthough I can see no change to the=
=20
original except the deleted user.

=46urther more:
I have recognized that after the action there's an empty file=20
called ".wh.webmin.acl" with executing!! rights. What is this supposed to b=
e?

Solution:
Meanwhile the only solutin is to delete this file (.wh.webmin.acl) manually=
=2E=20
What is this file about? Why is it blocking my access to modules, allthough=
=20
it's empty? How can this be fixed?

Thanks for help and answers
Thomas
=20
=2D-
Bitte nur an die Liste antworten, pers=F6nliche Mails werden gel=F6scht.
Please only answer to this list, personal mails will be deleted.

Re: [webmin-devel] Improvement to apache module's "edit config files"

[Jamie C. <jca...@we...>]

Hi Joseph,
That's a nice patch, although I'm not totally sure that it belongs in the 
Apache module in the core Webmin distribution ... mainly because I am working
on a new separate module for editing the PHP configuration file, in a user-friendly
way. It should be out in a release or two ..

 - Jamie

On 3/Nov/2006 14:00 Fry, Joseph wrote ..
> I have developers who need access to view the apache log files, and edit
> php.ini on our server.  Unfortunately, I cannot give those developers access
> to the logs module or the file manager module.  So, to meet their need
> I modified apache/allmanual_save.cgi and apache/allmanual_form.cgi as follows.
> I am not an experienced developer, so I am unfamiliar with submitting patches,
> but I felt that this would be a valuable feature to include in future releases,
> if anyone is willing to review and improve my code for submittion, I would
> appreciate it!
> 
> Essentially, these modifications cause a file in the module's directory
> (should be in /etc/ but I didn't take the time to do this) called "editfiles.ini"
> to be parsed, and appends any line that is not started with a # or whitespace
> to be added to the dropdown list of files to edit.  If any line begins
> with "ro ", that file is read-only.
> 
> If a file is read-only, the submit button is removed, and the file name
> is italicised in the dropdown box.  Users will not be able to save a read-only
> file.
> 
> The files I started with were from webmin Version 1.300.  I am sorry I
> do not have a diff file.
> 
> Thank you all for a great product!
> 
> Joe Fry
> 
> -----------------------------------------------------------
> #!/usr/bin/perl
> # allmanual_save.cgi
> # Save an entire config file
> 
> require './apache-lib.pl';
> &ReadParseMime();
> $access{'types'} eq '*' && $access{'virts'} eq '*' ||
>         &error($text{'manual_ecannot'});
> 
> $conf = &get_config();
> @files = &unique(map { $_->{'file'} } @$conf);
> 
> $editfiles = &read_file_lines("editfiles.ini");
> foreach $editfile (@$editfiles) {
>         if ($editfile !~ /^#/ and $editfile !~ /^$|^\s+/)
>         {
>                 if ($editfile !~ /^ro\s/)
>                 {
>                         push(@files, $editfile);
>                 }
>         }
> }
> 
> &indexof($in{'file'}, @files) >= 0 || &error($text{'manual_efile'});
> 
> $temp = &transname();
> &execute_command("cp ".quotemeta($in{'file'})." $temp");
> $in{'data'} =~ s/\r//g;
> &lock_file($in{'file'});
> &open_tempfile(FILE, ">$in{'file'}");
> &print_tempfile(FILE, $in{'data'});
> &close_tempfile(FILE);
> &unlock_file($in{'file'});
> if ($config{'test_manual'}) {
>         $err = &test_config();
>         if ($err) {
>                 &execute_command("mv $temp '$in{'file'}'");
>                 &error(&text('manual_etest', "<pre>$err</pre>"));
>                 }
>         }
> unlink($temp);
> &webmin_log("manual", undef, undef, { 'file' => $in{'file'} });
> &redirect("");
> -------------------------------------------------------------------
> #!/usr/bin/perl
> # allmanual_form.cgi
> # Display a text box for manually editing directives from one of the files
> 
> require './apache-lib.pl';
> &ReadParse();
> $access{'types'} eq '*' && $access{'virts'} eq '*' ||
>         &error($text{'manual_ecannot'});
> &ui_print_header(undef, $text{'manual_configs'}, "");
> 
> $conf = &get_config();
> @files = grep { -f $_ } &unique(map { $_->{'file'} } @$conf);
> 
> # ADD FILES TO EDIT OR DISPLAY IN editfiles.ini
> 
> $editfiles = &read_file_lines("editfiles.ini");
> foreach $editfile (@$editfiles) {
>         if ($editfile !~ /^#/ and $editfile !~ /^$|^\s+/)
>         {
>                 push(@files, $editfile);
>         }
> }
> $in{'file'} = $files[0] if (!$in{'file'});
> print "<form action=allmanual_form.cgi>\n";
> print "<input type=submit value='$text{'manual_file'}'>\n";
> print "<select name=file>\n";
> foreach $f (@files) {
>         if ($f =~ /^ro\s/) {
>                 $format = "style='font-style: italic'";
>         } else {
>                 $format = "";
>         }
>         printf "<option %s %s>%s\n",
>                 $format, $f eq $in{'file'} ? 'selected' : '', $f;
>         $found++ if ($f eq $in{'file'});
>         }
> print "</select>Files in italics are Read Only</form>\n";
> $found || &error($text{'manual_efile'});
> 
> if ($in{'file'} =~ /^ro\s/)
> {
>         print "<form action=allmanual_form.cgi method=post ",
>                 "enctype=multipart/form-data>\n";
>         $buttontype = "hidden";
>         $filename = $in{'file'};
>         $filename =~ s/^ro\s//;
> } else {
>         print "<form action=allmanual_save.cgi method=post ",
>                 "enctype=multipart/form-data>\n";
>         $buttontype = "submit";
>         $filename = $in{'file'};
> }
> print "<input type=hidden name=file value='$in{'file'}'>\n";
> print "<textarea name=data rows=20 cols=80 style='width:100%'>";
> open(FILE, $filename);
> while(<FILE>) { print &html_escape($_); }
> close(FILE);
> print "</textarea><br>\n";
> print "<input type=$buttontype value='$text{'save'}'>\n";
> print "</form>\n";
> 
> &ui_print_footer("", $text{'index_return'});
> 
> -- 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.430 / Virus Database: 268.13.25/515 - Release Date: 11/3/2006
> 5:15 AM
>  
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> -
> 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

[webmin-devel] Improvement to apache module's "edit config files"

[Fry, J. <jf...@ev...>]

I have developers who need access to view the apache log files, and edit =
php.ini on our server.  Unfortunately, I cannot give those developers =
access to the logs module or the file manager module.  So, to meet their =
need I modified apache/allmanual_save.cgi and apache/allmanual_form.cgi =
as follows.  I am not an experienced developer, so I am unfamiliar with =
submitting patches, but I felt that this would be a valuable feature to =
include in future releases, if anyone is willing to review and improve =
my code for submittion, I would appreciate it!

Essentially, these modifications cause a file in the module's directory =
(should be in /etc/ but I didn't take the time to do this) called =
"editfiles.ini" to be parsed, and appends any line that is not started =
with a # or whitespace to be added to the dropdown list of files to =
edit.  If any line begins with "ro ", that file is read-only.

If a file is read-only, the submit button is removed, and the file name =
is italicised in the dropdown box.  Users will not be able to save a =
read-only file.

The files I started with were from webmin Version 1.300.  I am sorry I =
do not have a diff file.

Thank you all for a great product!

Joe Fry

-----------------------------------------------------------
#!/usr/bin/perl
# allmanual_save.cgi
# Save an entire config file

require './apache-lib.pl';
&ReadParseMime();
$access{'types'} eq '*' && $access{'virts'} eq '*' ||
        &error($text{'manual_ecannot'});

$conf =3D &get_config();
@files =3D &unique(map { $_->{'file'} } @$conf);

$editfiles =3D &read_file_lines("editfiles.ini");
foreach $editfile (@$editfiles) {
        if ($editfile !~ /^#/ and $editfile !~ /^$|^\s+/)
        {
                if ($editfile !~ /^ro\s/)
                {
                        push(@files, $editfile);
                }
        }
}

&indexof($in{'file'}, @files) >=3D 0 || &error($text{'manual_efile'});

$temp =3D &transname();
&execute_command("cp ".quotemeta($in{'file'})." $temp");
$in{'data'} =3D~ s/\r//g;
&lock_file($in{'file'});
&open_tempfile(FILE, ">$in{'file'}");
&print_tempfile(FILE, $in{'data'});
&close_tempfile(FILE);
&unlock_file($in{'file'});
if ($config{'test_manual'}) {
        $err =3D &test_config();
        if ($err) {
                &execute_command("mv $temp '$in{'file'}'");
                &error(&text('manual_etest', "<pre>$err</pre>"));
                }
        }
unlink($temp);
&webmin_log("manual", undef, undef, { 'file' =3D> $in{'file'} });
&redirect("");
-------------------------------------------------------------------
#!/usr/bin/perl
# allmanual_form.cgi
# Display a text box for manually editing directives from one of the =
files

require './apache-lib.pl';
&ReadParse();
$access{'types'} eq '*' && $access{'virts'} eq '*' ||
        &error($text{'manual_ecannot'});
&ui_print_header(undef, $text{'manual_configs'}, "");

$conf =3D &get_config();
@files =3D grep { -f $_ } &unique(map { $_->{'file'} } @$conf);

# ADD FILES TO EDIT OR DISPLAY IN editfiles.ini

$editfiles =3D &read_file_lines("editfiles.ini");
foreach $editfile (@$editfiles) {
        if ($editfile !~ /^#/ and $editfile !~ /^$|^\s+/)
        {
                push(@files, $editfile);
        }
}
$in{'file'} =3D $files[0] if (!$in{'file'});
print "<form action=3Dallmanual_form.cgi>\n";
print "<input type=3Dsubmit value=3D'$text{'manual_file'}'>\n";
print "<select name=3Dfile>\n";
foreach $f (@files) {
        if ($f =3D~ /^ro\s/) {
                $format =3D "style=3D'font-style: italic'";
        } else {
                $format =3D "";
        }
        printf "<option %s %s>%s\n",
                $format, $f eq $in{'file'} ? 'selected' : '', $f;
        $found++ if ($f eq $in{'file'});
        }
print "</select>Files in italics are Read Only</form>\n";
$found || &error($text{'manual_efile'});

if ($in{'file'} =3D~ /^ro\s/)
{
        print "<form action=3Dallmanual_form.cgi method=3Dpost ",
                "enctype=3Dmultipart/form-data>\n";
        $buttontype =3D "hidden";
        $filename =3D $in{'file'};
        $filename =3D~ s/^ro\s//;
} else {
        print "<form action=3Dallmanual_save.cgi method=3Dpost ",
                "enctype=3Dmultipart/form-data>\n";
        $buttontype =3D "submit";
        $filename =3D $in{'file'};
}
print "<input type=3Dhidden name=3Dfile value=3D'$in{'file'}'>\n";
print "<textarea name=3Ddata rows=3D20 cols=3D80 style=3D'width:100%'>";
open(FILE, $filename);
while(<FILE>) { print &html_escape($_); }
close(FILE);
print "</textarea><br>\n";
print "<input type=3D$buttontype value=3D'$text{'save'}'>\n";
print "</form>\n";

&ui_print_footer("", $text{'index_return'});

--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.430 / Virus Database: 268.13.25/515 - Release Date: =
11/3/2006 5:15 AM
=20

[webmin-devel] Some updated info on my LDAP Users and Groups admin problem..

[bualum1998 <bua...@gm...>]

I've been doing some experimenting, and I am now able to create users
WITHOUT the SAMBA options enabled..

When I migrated users over from my existing /etc/passwd file I followed the
"SAMBA BY EXAMPLE" at www.samba.org, so all my users have the following
objectClasses:
top , person , organizationalPerson , inetOrgPerson , sambaSamAccount ,
posixAccount , shadowAccount

With the webmin, my new users have top, inetOrgPerson, posixAccount,
ShadowAccount

I continue to get an error about the sambaSID being required by
sambaSAMAccount.  I do have the Samba Domain SID set, and when I look at my
ldap log file, it does not appear to be including sambaSID in the paramaters
to set with the user add (or modify).

I've also noticed that my existing users have SambaSID set, and the SID is
the same as the Samba Domain SID, except for the last collection of digits,
these seem to vary by user.

How is ths SambaSID calculated, and how do I get webmin to set this value
when adding/creating users?

Thanks again for the help in advance.

[webmin-devel] LDAP Users and Groups Admin

[bualum1998 <bua...@gm...>]

What is the proper way to configure the module for LDAP users and Groups?

It defaults to using the inetorgperson objectclass, and if I try and add a
user without SAMBA support enabled, I get this error message:
Failed to save user : Failed to add user to LDAP database : no
structuralObjectClass operational attribute
If I enable SAMBA support, I get:

object class 'sambaSamAccount' requires attribute 'sambaSID'
Where as earlier I was getting errors: objectclass: value #2 invalid per
synta
I have the Domain SID for Samba3 set based on the net getlocalsid command..

Primary group SID is set to "Work out automatically"

Any help would be greatly appreciated.   I've tried several other web based
admin tools and this is the closest I've come to getting one working!

Thanks in advance.

Re: [webmin-devel] Webmin 1.280 pre-release now available

[Jamie C. <jca...@we...>]

Hi Klaus,
Yes, that would be nice ... but it is also tricky, as it means that the
module's current method of updating the zone files directly has to
be re-written. It is on my long-term TODO list though..

 - Jamie

-----Original Message-----

From:  Klaus Steinberger <Kla...@ph...>
Subj:  Re: [webmin-devel] Webmin 1.280 pre-release now available
Date:  Fri 16 Jun 2006 5:01 am
Size:  585 bytes
To:  web...@li...

Hi Jamie,

what about support in the bind module for Dyn DNS? Would be very interesting.

Sincerly,
Klaus

Re: [webmin-devel] Webmin 1.280 pre-release now available

[Klaus S. <Kla...@ph...>]

Hi Jamie,

what about support in the bind module for Dyn DNS? Would be very interesting.

Sincerly,
Klaus

-- 
Klaus Steinberger         Maier-Leibnitz Labor
Phone: (+49 89)289 14287  Am Coulombwall 6, D-85748 Garching, Germany
FAX:   (+49 89)289 14280  EMail: Kla...@Ph...
URL: http://www.physik.uni-muenchen.de/~k2/

In a world without Walls and Fences, who needs Windows and Gates

[webmin-devel] Webmin 1.280 pre-release now available

[Jamie C. <jca...@we...>]

Hi Webmin developers and translators,

Webmin 1.280 will be coming out soon, so I have created a 1.279 
development pre-release for interested people to test before the 
official 1.280 version comes out. Translators should also take a look 
at this version to find any new strings that need conversion.

You can get the 1.279 version from :

http://download.webmin.com/devel/tarballs/webmin-1.279.tar.gz
or
http://download.webmin.com/devel/rpm/webmin-1.279-1.noarch.rpm

The biggest changes in this new version are :

 - A new theme called 'Simple Blue' that uses much fewer
   images than the current 'MSC' theme (and may eventually
   become the default).
 - Code cleanups in modules that display tables to use a new
   API, and to support mass deletion where it was lacking.
 - Multiple hosts can be selected for each monitor in the 
   System and Server Status module.
 - Support for tunneling connections to another server in
   the SSH/Telnet Login module.

A full change log is available at :
http://www.webmin.com/changes-1.279.html


A pre-release 1.209 version of Usermin is also available,
which fixes many bugs in the Read Mail module, improves
search speed for Maildir mailboxes, adds auto-clearing of
folders and generally cleans up the code. This is available
from :

http://download.webmin.com/devel/tarballs/usermin-1.209.tar.gz
or
http://download.webmin.com/devel/rpm/usermin-1.209-1.noarch.rpm

 - Jamie

RE: [webmin-devel] hello

[Tan R. <tr...@ho...>]

You can't use webmin "for" vpn.
You can use webmin to configure certain vpns. What kind of vpn are you 
using?




----Original Message Follows----
From: jalpa vora <ja...@ya...>
Reply-To: web...@li...
To: web...@li...
Subject: [webmin-devel] hello
Date: Mon, 10 Apr 2006 06:38:21 -0700 (PDT)

how can i use wemin for my vpn

---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ 
countries) for 2¢/min or less.

[webmin-devel] hello

[jalpa v. <ja...@ya...>]

how can i use wemin for my vpn
		
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.