Solved

Installing spamassassin3.1.3 for system-wide use

Posted on 2006-06-22
12
426 Views
Last Modified: 2013-12-16
I have RHESv3 with perl v5.8.0 and with that version of perl the latest version of spamassassin is recommended, so I went to Apache's download site (Redhat's rpm for spamassassin is old).  The site says that 'rpmbuild -tb Mail-Spamassassin-3.1.3.tar.gz' will build an rpm, however in my case it only extracts the files to /usr/src/redhat/BUILD/Mail-SpamAssassin-3.1.3.  I had already gunzip'd and tar -xvf'd it the file to my desktop and don't see what advantage rpmbuild confers, unless this outcome indicates a problem with my OS.  Pls advise whether there's a problem and if not, whether I should install spamassassin from $HOME/Desktop, /usr/src/redhat/BUILD, or whether it just doesn't matter, thanks.

I read the INSTALL file in the Mail-Spamassassin folder, and it tells me what the required and optional perl modules are (I have all the required and some of the optional modules installed - some conflicted with perl5.8 and others weren't available as rpm's - figured this is complicated enough without installing perl modules from source).  So far, so good.  

However, the INSTALL file only provides instructions on installing spamassassin for personal use (not system-wide).  I need a system-wide install and understand that the usual procedure for that is .configure, make and make install, however there are two directories with configure and makefiles, spamc and spamd, and I hesitate to proceed until I know why /how to proceed  - I'm afraid the documentation may be spread out among files meant for more experienced administrators than myself :(

For the record, the "personal use" instructions from the INSTALL file say to:
- perl Makefile.PL PREFIX=$HOME
-make
-make install

If this is recommended for system-wide installs as well, I'd need to know why '.configure' is omitted, whether I should run these commands twice (for spamc and then spamd), and whether this  would this work:
- perl Makefile.PL PREFIX=/var/spool/mail


0
Comment
Question by:klukac
  • 6
  • 6
12 Comments
 
LVL 22

Assisted Solution

by:pjedmond
pjedmond earned 500 total points
Comment Utility
Starting at the beginning.

1.    The rpm system acknowledges that Perl has its own package management system. Hence the rpm provides the necessary source, and does not try to install anything relating to Perl. Perl does that for itself. The rpmbuild capability doesn't really provide anything extra (as the perl package manager will manage it for you) other than consistency in delivery of the source.

2.    With respect to the installation of Perl modules, I can 100% recommend webmind www.webmin.com Under it's other category, it provides a nice easy interface for managing Perl modules. This will make it easier to manage your installing/removing your Perl modules (but I guess it's a matter of choice). I 'deliver' all permodules to my system as tar.gz files and let webmin handle the management rather than using the rpm system. This is of ourse a matter of preference.

3.    The personal use:

- perl Makefile.PL PREFIX=$HOME
-make
-make install

is fine. For a global setup, you should be able to:

- perl Makefile.PL
-make
-make install

4.   .configure is ommitted, because perl modules use the perl configuration process: (perl Makefile.PL) which provides the equivalent process.

5.    - perl Makefile.PL PREFIX=/var/spool/mail

would work, but would stick spam assassin in a rather non-intuitive location. /var/spool/mail is normally where you stick your mail files (rather than binaries or utilities). Therefore, either:

- perl Makefile.PL

which should stick spamassassin in the default locations (in my case spamd and spamc ended up in /usr/bin, or

- perl Makefile.PL PREFIX=/var/sa

or something similar.

6.    spamd and spamc are part of the 'perl module/package' The aforementioned process only needs to be run once.

(   (()
(`-' _\
 ''  ''
0
 

Author Comment

by:klukac
Comment Utility
Great stuff, thanks.  I finally installed Webmin, which I had avoided until now, maybe because I was prescient of the problems
I now face.  Here are the latest perl modules that Webmin recommends for my system:

Authen::Libwrap (Webmin Configuration)
Authen::PAM (PAM Authentication)
DBD::Pg (PostgreSQL Database Server)
DBD::mysql (MySQL Database Server)
DBI (PostgreSQL Database Server)
IO::Pty (Running Processes)
Net::LDAP (LDAP Users and Groups)
Net::SSLeay (Webmin Configuration)
Sys::Syslog (Webmin Configuration)

At first Webmin couldn't find CPAN.pm and prompted me to do a manual install.
I ended up installing Bundle::CPAN, after a shell prompt/warning when I tried installing an older CPAN.pm file.  I thought the bundle was ok, because the prompts explained to accept if you didn't know the answer and not to worry if you didn't have a program CPAN was looking for.  I didn't read until later that cpan recommends using Build.PL instead of Makefile.PL to build its modules, but the installation was ok and the CPAN.pm errors disappeared. My errors were that ncftp and ncftpget were not present (didn't know what version to install of each), and that Net::Cmd failed to install.

So I tried installing the perl modules again via Webmin.  Webmin takes an enormous amount of time just to display the modules I have installed, and when I attempt to install even a single module, it takes up to 50% of my CPU processing power and then fails, presumably due to a permissions problem.  I therefore opted for a manual install again.  Here's where the nightmare begins:
The first module, Authen-Libwrap, fails to install, prompting me to reinstall Module::Build (Webmin lists Module::Build as installed, but doesn't show an error).  Maybe because I was using Makefile.PL rather than Build.PL, not sure.

So I downloaded Module::Build and tried to reinstall it but got this:
Module::Build error, the following are (optional) prereqs
 * Optional prerequisite ExtUtils::ParseXS is not installed
 * Optional prerequisite Pod::Readme is not installed
 * Optional prerequisite ExtUtils::CBuilder is not installed

Then I downloaded and installed ExtUtils, and got this error:
ExtUtils::CBuilder needed for ExtUtils::ParseXS

Authen-Libwrap being only the first module of the Webmin-recommended list, I don't know that I will live long enough to see every recommended module installed at the rate I'm going... Webmin now shows that nine additional modules are needed where only six were needed before I installed Bundle::CPAN.  I have 40 perl modules installed, up from an initial 22.  Needless to say I haven't gotten to the 10 supposedly optional modules on the spamassassin list, and have no idea how to proceed.  My system has plenty of room on it, but I have limited cache/RAM.
0
 
LVL 22

Assisted Solution

by:pjedmond
pjedmond earned 500 total points
Comment Utility
Oh dear - we really need all of these installs to be as clean as possible! The fact that you are getting these problems makes me think that some of your modules have previously been installed manually, and are not 100% consistent with the overall perl setup. By using a single tool to add and remove your modules, irritating problems like this can be avoided.

First thing that appears to have happened, is that you've been very reserved in your installation. The perl rpms on my system (a RHEL3 system, on which spam assassin installs cleanly via webmin) are:

perl-DB_File-1.804-88.4
perl-DateManip-5.40-30
perl-XML-Twig-3.09-3
newt-perl-1.08-4
perl-Digest-HMAC-1.01-11.1
mod_perl-1.99_09-10.ent
perl-CGI-2.81-88.4
perl-SGMLSpm-1.03ii-11
perl-DBD-MySQL-2.1021-3
perl-XML-Encoding-1.01-23
perl-libxml-perl-0.07-28
perl-CPAN-1.61-88.4
perl-libxml-enno-1.02-29
perl-DBD-Pg-1.21-2
perl-Time-HiRes-1.38-3
perl-libwww-perl-5.65-6
perl-Net-DNS-0.31-3.1
perl-HTML-Tagset-3.03-28
perl-XML-Parser-2.31-15
perl-Parse-Yapp-1.05-30
perl-Digest-SHA1-2.01-15.1
perl-HTML-Parser-3.26-17
perl-5.8.0-88.4
perl-URI-1.21-7
perl-XML-Dumper-0.4-25
perl-XML-Grove-0.46alpha-25
perl-DBI-1.32-5
perl-Filter-1.29-3

These were installed from the RHEL CDs. You need these tools, because perl needs to be able to read/parse and compile source code in order to enable it to install modules. (Effectively, you need the development environment in order to be able to do this). I know this is a little on the painfully slow side, but I recommend that:

1. If possible, you uninstall anything that you have tried to manually install.
2. Install any of the above perl rpms that are on your install CDs. (If the rpm is missing, then perl tries to download a perl based replacement!...which slows down compilation performance). particularly the ones with either 'parse' or XML in the title.
3. Retry your install process.

Only install problem I got was:

dns: Net::DNS version is 0.31, but need 0.34 (required for some functions - however, the install still completed)

I then upgraded Net::DNS, and everything seems to be OK.

Unfortunately, there are a lot of 'bits' required to get this to work, but once it's working, it's awesome:)

(   (()
(`-' _\
 ''  ''




0
 

Author Comment

by:klukac
Comment Utility
Thanks very much.  My RHES had slowed to a crawl, so I've proceeded very cautiously.  Nothing was installed via cpan yesterday, so I did a search on modified files from manual installs and there wasn't anything to remove outside my $HOME/Desktop and root/.cpan files that I can recall.  The root/.cpan files are still there, but I wasn't sure whether to delete that folder, which is harmless I assume.  However I found that these files had been modified:
/var/lib/rpm/Packages
/var/lib/rpm/Providename
/var/lib/rpm/Requireversion
/var/lib/rpm/Basenames
/var/lib/rpm/Name
/var/lib/rpm/Group
/var/lib/rpm/Requirename
/var/lib/rpm/Dirnames
/var/lib/rpm/Provideversion
/var/lib/rpm/Installtid
/var/lib/rpm/Sigmd5
/var/lib/rpm/Sha1header
/var/lib/rpm/Filemd5s
/var/lib/rpm/Triggername
Don't know what this means/whether I should be worried about it.  I've checked my list of perl rpm's against yours, and the only ones I'm missing are perl-SGMLSpm and perl-DBD-Pg.  I can install these and  rpm -Uvh the rest, but should I do something about the above first?
Another thing that concerns me is that my webmin version 1.280 bind files are labeled bind8, but I have bind9.  

   
0
 
LVL 22

Assisted Solution

by:pjedmond
pjedmond earned 500 total points
Comment Utility
Slowed to a crawl.....shouldn't happen? I presume that:

top

shows nothing odd?

/var/lib/rpm contains all the data and information that allow the rpm package manager to keep track of what's in the system.

The ones that you are missing are probably not necessary, so don't worry about them. However, I'd agree that an rpm -Uvh against the rest may be helpful, or alternatively a F (freshen) may be in order as well?

Bind 8 and Bind 9 configuration directives are pretty similar. Webmin modules are generally very good about not touching lines it doesn't understand. I would not be concerned, unless I'm trying to use some of the advanced functions (which you probably won't be?). If you need to start dealling with authentication with other servers, then edif the conf file manually.

(   (()
(`-' _\
 ''  ''
0
 

Author Comment

by:klukac
Comment Utility
Thanks, so far rpm -Uvh is showing that the modules are already installed, but on a couple I get a conflict with perl 5.8 on the man3 files, which carry the same name in perl 5.8 so there must be a duplication of help files.  I have a question in to redhat on whether to ignore or force it, and whether this is a redhat error or what.  So I'll see what they say.  
The attempted installs of the pm's, with webmin in particular, were slowing down my system.  Didn't notice any glaring problem in 'top' after exiting webmin, but it wasn't until after I rebooted that my system started behaving normally again...must have been a memory leak somewhere and I didn't know what to look for.  
Anyway, I should probably understand a little more about webmin vs cpan vs rpm installs of pm's before going on.  If webmin manages perl modules, shouldn't it show the same results as 'rpm -qa |grep perl'?  If I'm to continue using rpm to install/update perl modules, what is the benefit of webmin?
0
IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 22

Assisted Solution

by:pjedmond
pjedmond earned 500 total points
Comment Utility
Perl modules from CPAN are all tar.gz files, and as such are not monitored by the rpm system.

The rpm system is nice, but for any given distribution, the only Perl modules that get bundled into rpms are the most common ones. The moment that you try to use anything beyond this, then the rpm system cannot help you (unless you are prepared to start making your own RPMs).

The Webmin system gives you the same results as using the CPAN approach (but Webmin does it nice and graphically, and you never need to worry about remembering the syntax, or finding the correct file.

As a result, after installing the 'common' rpms that provide dependencies to apache etc, I install all additional perl modules using either CPAN or webmin.

If the conflict is related to the man files, then you can either ignore or force the install - Either will work. Just be aware that some of your man files(documentation) won't be 100% accurate.

      
Comment from pjedmond
Date: 06/23/2006 09:00AM BST
      Your Comment       

Starting at the beginning.

1.    The rpm system acknowledges that Perl has its own package management system. Hence the rpm provides the necessary source, and does not try to install anything relating to Perl. Perl does that for itself. The rpmbuild capability doesn't really provide anything extra (as the perl package manager will manage it for you) other than consistency in delivery of the source.

2.    With respect to the installation of Perl modules, I can 100% recommend webmind www.webmin.com Under it's other category, it provides a nice easy interface for managing Perl modules. This will make it easier to manage your installing/removing your Perl modules (but I guess it's a matter of choice). I 'deliver' all permodules to my system as tar.gz files and let webmin handle the management rather than using the rpm system. This is of ourse a matter of preference.

3.    The personal use:

- perl Makefile.PL PREFIX=$HOME
-make
-make install

is fine. For a global setup, you should be able to:

- perl Makefile.PL
-make
-make install

4.   .configure is ommitted, because perl modules use the perl configuration process: (perl Makefile.PL) which provides the equivalent process.

5.    - perl Makefile.PL PREFIX=/var/spool/mail

would work, but would stick spam assassin in a rather non-intuitive location. /var/spool/mail is normally where you stick your mail files (rather than binaries or utilities). Therefore, either:

- perl Makefile.PL

which should stick spamassassin in the default locations (in my case spamd and spamc ended up in /usr/bin, or

- perl Makefile.PL PREFIX=/var/sa

or something similar.

6.    spamd and spamc are part of the 'perl module/package' The aforementioned process only needs to be run once.

(   (()
(`-' _\
 ''  ''

Comment from klukac
Date: 06/24/2006 05:42AM BST
      Author Comment       

Great stuff, thanks.  I finally installed Webmin, which I had avoided until now, maybe because I was prescient of the problems
I now face.  Here are the latest perl modules that Webmin recommends for my system:

Authen::Libwrap (Webmin Configuration)
Authen::PAM (PAM Authentication)
DBD::Pg (PostgreSQL Database Server)
DBD::mysql (MySQL Database Server)
DBI (PostgreSQL Database Server)
IO::Pty (Running Processes)
Net::LDAP (LDAP Users and Groups)
Net::SSLeay (Webmin Configuration)
Sys::Syslog (Webmin Configuration)

At first Webmin couldn't find CPAN.pm and prompted me to do a manual install.
I ended up installing Bundle::CPAN, after a shell prompt/warning when I tried installing an older CPAN.pm file.  I thought the bundle was ok, because the prompts explained to accept if you didn't know the answer and not to worry if you didn't have a program CPAN was looking for.  I didn't read until later that cpan recommends using Build.PL instead of Makefile.PL to build its modules, but the installation was ok and the CPAN.pm errors disappeared. My errors were that ncftp and ncftpget were not present (didn't know what version to install of each), and that Net::Cmd failed to install.

So I tried installing the perl modules again via Webmin.  Webmin takes an enormous amount of time just to display the modules I have installed, and when I attempt to install even a single module, it takes up to 50% of my CPU processing power and then fails, presumably due to a permissions problem.  I therefore opted for a manual install again.  Here's where the nightmare begins:
The first module, Authen-Libwrap, fails to install, prompting me to reinstall Module::Build (Webmin lists Module::Build as installed, but doesn't show an error).  Maybe because I was using Makefile.PL rather than Build.PL, not sure.

So I downloaded Module::Build and tried to reinstall it but got this:
Module::Build error, the following are (optional) prereqs
 * Optional prerequisite ExtUtils::ParseXS is not installed
 * Optional prerequisite Pod::Readme is not installed
 * Optional prerequisite ExtUtils::CBuilder is not installed

Then I downloaded and installed ExtUtils, and got this error:
ExtUtils::CBuilder needed for ExtUtils::ParseXS

Authen-Libwrap being only the first module of the Webmin-recommended list, I don't know that I will live long enough to see every recommended module installed at the rate I'm going... Webmin now shows that nine additional modules are needed where only six were needed before I installed Bundle::CPAN.  I have 40 perl modules installed, up from an initial 22.  Needless to say I haven't gotten to the 10 supposedly optional modules on the spamassassin list, and have no idea how to proceed.  My system has plenty of room on it, but I have limited cache/RAM.

Comment from pjedmond
Date: 06/24/2006 11:05AM BST
      Your Comment       

Oh dear - we really need all of these installs to be as clean as possible! The fact that you are getting these problems makes me think that some of your modules have previously been installed manually, and are not 100% consistent with the overall perl setup. By using a single tool to add and remove your modules, irritating problems like this can be avoided.

First thing that appears to have happened, is that you've been very reserved in your installation. The perl rpms on my system (a RHEL3 system, on which spam assassin installs cleanly via webmin) are:

perl-DB_File-1.804-88.4
perl-DateManip-5.40-30
perl-XML-Twig-3.09-3
newt-perl-1.08-4
perl-Digest-HMAC-1.01-11.1
mod_perl-1.99_09-10.ent
perl-CGI-2.81-88.4
perl-SGMLSpm-1.03ii-11
perl-DBD-MySQL-2.1021-3
perl-XML-Encoding-1.01-23
perl-libxml-perl-0.07-28
perl-CPAN-1.61-88.4
perl-libxml-enno-1.02-29
perl-DBD-Pg-1.21-2
perl-Time-HiRes-1.38-3
perl-libwww-perl-5.65-6
perl-Net-DNS-0.31-3.1
perl-HTML-Tagset-3.03-28
perl-XML-Parser-2.31-15
perl-Parse-Yapp-1.05-30
perl-Digest-SHA1-2.01-15.1
perl-HTML-Parser-3.26-17
perl-5.8.0-88.4
perl-URI-1.21-7
perl-XML-Dumper-0.4-25
perl-XML-Grove-0.46alpha-25
perl-DBI-1.32-5
perl-Filter-1.29-3

These were installed from the RHEL CDs. You need these tools, because perl needs to be able to read/parse and compile source code in order to enable it to install modules. (Effectively, you need the development environment in order to be able to do this). I know this is a little on the painfully slow side, but I recommend that:

1. If possible, you uninstall anything that you have tried to manually install.
2. Install any of the above perl rpms that are on your install CDs. (If the rpm is missing, then perl tries to download a perl based replacement!...which slows down compilation performance). particularly the ones with either 'parse' or XML in the title.
3. Retry your install process.

Only install problem I got was:

dns: Net::DNS version is 0.31, but need 0.34 (required for some functions - however, the install still completed)

I then upgraded Net::DNS, and everything seems to be OK.

Unfortunately, there are a lot of 'bits' required to get this to work, but once it's working, it's awesome:)

(   (()
(`-' _\
 ''  ''





Comment from klukac
Date: 06/24/2006 09:34PM BST
      Author Comment       

Thanks very much.  My RHES had slowed to a crawl, so I've proceeded very cautiously.  Nothing was installed via cpan yesterday, so I did a search on modified files from manual installs and there wasn't anything to remove outside my $HOME/Desktop and root/.cpan files that I can recall.  The root/.cpan files are still there, but I wasn't sure whether to delete that folder, which is harmless I assume.  However I found that these files had been modified:
/var/lib/rpm/Packages
/var/lib/rpm/Providename
/var/lib/rpm/Requireversion
/var/lib/rpm/Basenames
/var/lib/rpm/Name
/var/lib/rpm/Group
/var/lib/rpm/Requirename
/var/lib/rpm/Dirnames
/var/lib/rpm/Provideversion
/var/lib/rpm/Installtid
/var/lib/rpm/Sigmd5
/var/lib/rpm/Sha1header
/var/lib/rpm/Filemd5s
/var/lib/rpm/Triggername
Don't know what this means/whether I should be worried about it.  I've checked my list of perl rpm's against yours, and the only ones I'm missing are perl-SGMLSpm and perl-DBD-Pg.  I can install these and  rpm -Uvh the rest, but should I do something about the above first?
Another thing that concerns me is that my webmin version 1.280 bind files are labeled bind8, but I have bind9.  

   

Comment from pjedmond
Date: 06/24/2006 10:23PM BST
      Your Comment       

Slowed to a crawl.....shouldn't happen? I presume that:

top

shows nothing odd?

/var/lib/rpm contains all the data and information that allow the rpm package manager to keep track of what's in the system.

The ones that you are missing are probably not necessary, so don't worry about them. However, I'd agree that an rpm -Uvh against the rest may be helpful, or alternatively a F (freshen) may be in order as well?

Bind 8 and Bind 9 configuration directives are pretty similar. Webmin modules are generally very good about not touching lines it doesn't understand. I would not be concerned, unless I'm trying to use some of the advanced functions (which you probably won't be?). If you need to start dealling with authentication with other servers, then edif the conf file manually.

(   (()
(`-' _\
 ''  ''
0
 

Author Comment

by:klukac
Comment Utility
Sorry about this, for reasons which pass my understanding my last post didn't show up, and since then I've been on travel.  According to Redhat, packages perl-MIME-Base64 and perl-Digest-MD5 are available with RHEL 2.1 only, which would explain the conflict on my RHES 3, so those are packages I should probably uninstall.  At this point I need to get a better handle on how the pieces fit together.  As I understand it, cpan command line installs require tracking submodules, so that any perl module installation can take an enormous amount of time.  
rpm installs avoid this, as do webmin installs, but webmin can help me take advantage of the most recent perl modules.  Since two overlapping management systems are not a good idea, I'll need to a) verify the integrity of my system, and before asking redhat to look at it, I need to understand where Bundle::CPAN perl modules are supposed to be installed - when I checked webmin before leaving (the webmin port isn't open on my firewall) the same ~ 40 pm's that appeared after my manual install of Bundle::CPAN were still there, but I can't find them in my terminal window (either 'find' or 'locate' don't lend themselves to this sort of lookup or I'm using them incorrectly).  As I mention above, rpm -qa |grep perl shows a list of some 26 perl modules, which I'm assuming represent only those perl modules installed via rpm, not those that were installed with Bundle::CPAN.  b) since I could not install a perl module with webmin or cpan, I'll need to figure out how permissions for this are set up.  Of course it would have helped if I had bothered to check /var/log/messages, but it's kind of scary to try installing something that way anyway.

Let me know if my understanding is correct, how to verify webmin's list of perl modules in my terminal window, and what permissions webmin needs to work as advertised, thanks.
0
 
LVL 22

Accepted Solution

by:
pjedmond earned 500 total points
Comment Utility
>perl-MIME-Base64 and perl-Digest-MD5 are available with RHEL 2.1 only, which would explain the conflict on my RHES 3, so those are packages I should probably uninstall

If they were installed via rpm, then rpm -e would be a good idea merely to prevent confusion later (BUT ONLY IF THERE ARE NO DEPENDENCIES WHEN YOU TRY TO REMOVE) , and then install via webmin interface. If there are dependencies - just reinstall using webmin - This will cause problems with some types of upgrades, so a note must be mad of it in your server records.

>rpm -qa |grep perl shows a list of some 26 perl modules, which I'm assuming represent only those perl modules installed via rpm

Correct, only rpm installed packages show up in the rpm database.

As you quite rightly said, having more than one method for manageing modules that overlaps is bad! - But Redhat does not provide all the modules that you might want, and 1 area where I by default use webmin rather than rpm is for perl modules. In the same way I use pear for php.

All the perl modules installed by webmin live in the default location:

/usr/lib/perl5/site_perl/5.8.0/Archive/

for example. Redhat's install lives in:

/usr/lib/perl5/5.8.0/

so effectively you are ending up with 2 perl installations. Messy, but I leave the Redhat install directory to support all of the redhat rpms and never upgrade them unless a new security rpm comes out. For perl work, scripts, spamassassin etc, I use the webmin install. You could of course try manually move the .pms into the redhat folder, but then there are no dependency/linking checks etc, and that isn't a route that I'd want to take.

(   (()
(`-' _\
 ''  ''
0
 

Author Comment

by:klukac
Comment Utility
Again great stuff, thanks.  I'm not going to try installing anything via webmin during this trip, since I can't open the webmin port from here, and I won't be home for a while so I'd like to close this out, but I do have one unanswered question.  I'm not sure whether my earlier failure to install any pm's via webmin was caused by the fact that I didn't have the right modules from Bundle::CPAN installed, whether there was a permissions problem on my server, or both.  Given that I also couldn't install anything via the cpan command line tool indicates that my server permissions remain too restrictive to use another tool to install anything.  How do I check webmin permissions on my server (to install perl modules, spamassassin etc) and what should they be set to?
0
 
LVL 22

Assisted Solution

by:pjedmond
pjedmond earned 500 total points
Comment Utility
Webmin is effectively running as root, provided you haven't used the usermin functionality. You can confirm this with:

ps -ef | grep webmin


Installing via the CPAN tool is also a good method - I just happent to like using webmin:)

(   (()
(`-' _\
 ''  ''

0
 

Author Comment

by:klukac
Comment Utility
Ok, did that, got this:
ps -ef |grep webmin
root      2657     1  0 Jul03 ?        00:00:00 /usr/bin/perl /usr/local/webin/miniserv.pl /etc/webmin/miniserv.conf
root      9100  6678  0 02:06 pts/0    00:00:00 grep webmin

(webin is a typo that I made during install, but I'd have to reinstall and so I left it)

 I assume that since the webmin miniserver is running as root, I can try installing perl modules again with webmin when I return home.  If that's not the case, let me know, thanks.
0

Featured Post

What Is Threat Intelligence?

Threat intelligence is often discussed, but rarely understood. Starting with a precise definition, along with clear business goals, is essential.

Join & Write a Comment

Using 'screen' for session sharing, The Simple Edition Step 1: user starts session with command: screen Step 2: other user (logged in with same user account) connects with command: screen -x Done. Both users are connected to the same CLI sessio…
Join Greg Farro and Ethan Banks from Packet Pushers (http://packetpushers.net/podcast/podcasts/pq-show-93-smart-network-monitoring-paessler-sponsored/) and Greg Ross from Paessler (https://www.paessler.com/prtg) for a discussion about smart network …
Learn how to get help with Linux/Unix bash shell commands. Use help to read help documents for built in bash shell commands.: Use man to interface with the online reference manuals for shell commands.: Use man to search man pages for unknown command…
Learn how to navigate the file tree with the shell. Use pwd to print the current working directory: Use ls to list a directory's contents: Use cd to change to a new directory: Use wildcards instead of typing out long directory names: Use ../ to move…

771 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now