Yes, it is implemented as a seprate server, listening on port 1000.
We may want to take a different approach than this perse, due to the =
fact
that Webmin has been out for a while and "crackers" will probably be
sniffing that port.
I took a bit of a break from the project to regroup on some things th=
at were
going on at work.
Stuff is back in order now, the code I was working on at work is rele=
ased,
and I am free for discussion. If any of you would like to try ONCE A=
GAIN to
set up a meeting on IRC, or maybe even via the forum, lets get someth=
ing
together on that. So far, there only seems to be three of us really
interested in this. I'm thinking that if at least the three of us ca=
n work
out a time to meet, we could hack something out on this together.
Bigger groups, aren't always better..
Maybe it will be best this way.
If anyone else recieving these e-mails isn't going to reply, then I s=
ay they
be removed..
Thanks,
Ben
----- Original Message -----
=46rom: "Indira Virk" <indira_virk@...>
To: <tommy_butler@...>; "Stefan Ilivanov"
<ilivanov@...>
Cc: <Trinityos-perlwebmin@...>
Sent: Wednesday, June 26, 2002 12:37 AM
Subject: Re: [Trinityos-perlwebmin] What's up ?
> Sounds good. The reasons make a lot of sense.
> Incidently, if you've had a chance to look at Webmin,
> that too is implemented as a separate server.
>
> --- tommy_butler@... wrote:
> > Stefan Ilivanov wrote:
> > > It's there any progres with the administration
> > system ?
> >
> > I've brought forward the I/O utilities code which is
> > part of the webmin base
> > about 18 sub releases. It includes an implementation
> > of C flock(3) in pure
> > Perl which isn't portably available and is
> > error-prone in the core of the Perl
> > language itself.
> >
> > I've been planning something out which I probably
> > should present for public
> > approval before going forward with it anymore. I
> > already have figured out how
> > to implement this proposed action, so this isn't a
> > pie-in-the-sky idea. It's a
> > sub-sub project looking for approval and feedback.
> >
> > I propose that a seperate apache server be created
> > to specifically handle the
> > web admin. It should listen on a different port,
> > and be compiled differently
> > than the main thttpd web server. There are several
> > reasons this should happen,
> > and several reasons why it is beneficial. I'll go
> > over these from this point
> > forward.
> >
> > Due to the nature of a dedicated server, we can
> > profit from tactics
> > which wouldn't work for the main server. (read
> > on)
> >
> > The seperate apache binary can be a mod_perl
> > server and still be a
> > superfast, streamlined process. Because only
> > handles a few documents
> > and CGIs it keeps its registry optimally small.
> > There's nothing faster
> > than RAM, folks.
> >
> > The dedicated server can be compiled with the
> > inclusion of the base webmin
> > code and its supporting libs without losing
> > performance; even GAINing
> > performance by a significant measure.
> >
> > The dedicated server can be compiled with the
> > EXclusion of more apache mods
> > which would otherwise be neccessary on a
> > fully-functionally public apache
> > server. (eg- we don't need to compile it with a
> > bunch of language packs
> > which aren't used as the OS native language, no
> > need for logging when base
> > code already handles this much better with a
> > searchable interface, no need
> > for huge mime db, no need for server-side
> > scripting support other than the
> > perl, AND a whole bunch of other stuff.)
> >
> > The seperate httpd is going to be very
> > transparent and have a verrrrry small
> >
> > memory footprint while demanding fewer cpu
> > cycles. The dedicated server
> > can be safely limited to a small number of child
> > processes.
> >
> > A seperate apache binary allows us to avoid
> > getting muddled by, and
> > muddling up further the public web server with
> > all its issues.
> > We remain clear of the main server's operations
> > that have nothing to
> > do with us:
> >
> > load balancing policies for public documents
> > shouldn't interfere with us
> > Think about it for a moment: how can web
> > admin fix a hanging server if
> > it
> > RUNS ON IT?
> >
> > We don't need the same storage schedule, we
> > don't need to run
> > the same cron jobs, and the pub server really
> > doesn't need to be
> > messing around with ours!
> >
> > --especially if the inroad I'm working on provides
> > a further layer
> > of security between the web admin and the web
> > browser by putting
> > risky jobs in que for later admin approval with
> > strictly onsite
> > system access. I want my own crontab.
> >
> > Any special firewall rules for our server
> > don't need to slow down the
> > main
> > server, and vise versa.
> >
> > Our logging semantics and subprocesses are
> > different. We don't need
> > to run extra helper procs and subprocs for our
> > own programs. We don't
> > need to include our access hits in the traffic
> > reports, for a simple
> > example.
> >
> > We need different levels of access to the
> > machine's internals which
> > we shouldn't have to build into the main
> > server.
> >
> > We can easily target and eliminate intrusion
> > attempts on the web
> > admin (yes, they will happen) providing more
> > security by staying
> > away from the main server.
> >
> > If at any time we need or decide to use SSL,
> > we're going to have to
> > create another server anyway. This is gonna
> > be a super pain in the
> > butt if we have already built the webmin to
> > work as part of the public
> > server. This is yet another conflict we don't
> > need.
> >
> >
> > --
> >
> > -Tommy Butler
> > http://atrixnet.com
> >
> > I'm looking for work!
> > contract or perm, full or part time
> > Download my r=E9sum=E9
> > http://www.atrixnet.com/resume
> >
> > the ooOPps Code Library
> > http://ooopps.sourceforge.net/pub/
> >
> >
> >
> -------------------------------------------------------
> > This sf.net email is sponsored by: Jabber Inc.
> > Don't miss the IM event of the season | Special
> > offer for OSDN members!
> > JabConf 2002, Aug. 20-22, Keystone, CO
> > http://www.jabberconf.com/osdn
> > _______________________________________________
> > Trinityos-perlwebmin mailing list
> > Trinityos-perlwebmin@...
> >
> https://lists.sourceforge.net/lists/listinfo/trinityos-perlwebmin
>
>
> __________________________________________________
> Do You Yahoo!?
> LAUNCH - Your Yahoo! Music Experience
> http://launch.yahoo.com
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Jabber Inc.
> Don't miss the IM event of the season | Special offer for OSDN memb=
ers!
> JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/os=
dn
> _______________________________________________
> Trinityos-perlwebmin mailing list
> Trinityos-perlwebmin@...
> https://lists.sourceforge.net/lists/listinfo/trinityos-perlwebmin
|