[p][font face="Verdana, Arial, Helvetica, sans-serif"] I'm not sure if this is the right place to post this but there is a blue sky at the end.First of all Virtualmin has saved my life as far as trying to RE-setup and manage our small server in the shop. I've been living with Redhat 7.3 since the dawn of 7.3 just because it wouldn't die. It finely did so now I have to get somthing going and Virtualmin really helped.I've used Webmin for years and it has given me the ability to more easily understand and learn linux and now Virtualmin is like a magic pill to relieve my mental stress. Thanks.Here is what's going on.I'm trying to install [a href="http://www.icdevgroup.org/"][strong][font size="3"]Interchange[/reftxt][/strong][/url] and according to all I've read in their forums, you're better off to install a non-threaded perl along side of the stock threaded-perl which comes with CentOS. Interchange will run roughly 30% faster under non-threaded perl. Interchange runs ok under threaded-perl but just slower according to Interchange forum posts.OK first a little lead in.I started with a fresh install of CentOS and partitioned as directed in the Virtualmin docs. I did not use LVM because I wanted to use the Acronis True Image boot disk to backup and restore the main system and it can only work with ext3 partitions. Then virtualmin I hope can restore all the backed up domains quickly if it ever comes to that.This is a private home grown server so if it goes down and needs to be restored and it takes an hour or so to get it back up it's not a big deal since we're not a commercial hosting service.I created a full backup of CentOS with all the updates.Then I installed Virtualmin and got it working and made a second full backup which includes Virtualmin and one domain.Now here is the fun part.I then followed [a href="http://www.vermonster.com/articles/26/interchange-installation-on-redhat"][font size="3"]these instructions[/reftxt][/url] from vermonster.com as to the installation of non-threaded perl.This worked fine and when I installed interchange it went fine too but I found I had to install the interchange perl modules so the non-threaded perl would know about them. Modules like Bundle::Interchange and Bundle::InterchangeKitchenSink. Also had to install DBD::Mysql after that I think.I actually got it all working after a little fiddling with permissions of the usr/local/interchange installation directory.The permissions of the sockets file and some admin UI pages were problematic with permissions etc...Now interchange no longer complains about threaded-perl and everything looked good so I created another full backup using Acronis.When I booted back up after using the Acronis boot disk to do the backup I could no longer use virtualmin.I'm guessing the installation of non-threaded perl threw a wrench in the works but I didn't know until I rebooted the computer.So my question is, although it's recommended to install virtualmin on a freshly installed OS, I thought I would try to install non-threaded perl on the fresh OS first and then install virtualmin. Is this a valid path of thinking or is it better to install non-threaded perl after virtualmin as I did but with some perl install options which are not listed in the instructions I found at vermonster.com?Since I have several restore points and can go back to a clean CentOS install in like 3 minutes I'm going to experiment with this but I have a feeling my thinking may be flawed. I'm sure there will be something else I'll need to do to get non-threaded perl, to play nice along side of Virtualmin.I'll experiment in this order. I'm going to first try interchange on threaded-perl with virtualmin installed. I'm pretty sure this will work.Then after I get that working I'll restore to a virgin CentOS installation, install non-threaded perl first and then install virtualmin reboot and see if that works.I'll post my findings here after these experiments.In the meantime, If anyone has any suggestions I would be grateful. I really do like interchange and I LOVE Virtualmin and I'd like to try and get then in the play-pen together.Oh... and... You say blue sky project ideas are welcome. Feel free to dream big (-:: Thats me smiling with my glasses on.How about and auto-install combo for Non-Threaded Perl with Interchage done right. Not the messed up way that cPanel does it. Oh... and a way to make more than one catalog per domain.Now that is really Blue Sky (-::Thanks,John Wolgamot[/reftxt][/p]
Hey John,
First step would be to figure out why Virtualmin isn't running, as I don't see any errors listed in your post. I doubt a reinstall is needed, as Webmin doesn't use threads (it uses fork, which I believe always just spawns a new process). There may some missing modules in your from source build of the non-threaded perl. Webmin only uses standard modules, plus a couple of extras (PAM, primarily), but a custom build might skip some of the standard ones if you don't have the devel components available. SSL comes to mind.
Problems with your perl are probably going to come up again during a fresh installation, and then you'll be further behind than you are now.
Anyway, what happens on the command line when you try to restart Webmin?
service webmin restart
And what's in the /var/webmin/miniserv.error log? Anything in the other logs in that dir?
--
Check out the forum guidelines!
Thanks Joe,
I did try a service webmin restart and a list of perl files flew by which led me to the conclusion that my non-threaded perl install was the culprit.
I wasn't sure where to go from there so I did a restore and started again from a vanilla CentOS/Virtualmin checkpoint since that only takes a few minutes.
I bet you're right about the problem being some missing modules after the non-threaded perl install.
I've come a long way since Redhat7.3 and webmin back then but I still feel newbish which is one of the reasons I wasn't sure how to proceed or where to look for the webmin error logs so my quickest thought was an Acronis restore to start again from a known good checkpoint. Now I'll look in the logs the next time.
I will try again but before I install the non-threaded perl I'll make a list of installed perl modules and install them manually after the non-threaded perl is on the system.
I'll post the results here even if there is success.
Thanks again
John
John Wolgamot
Thanks for the tip Joe,
Just for the record, I did get Interchange working flawlessly under the stock install of Virtualmin/CentOS/threaded-Perl.
One has to ask, why do the Interchange developers stress using non-threaded perl just to get the 30% speed increase.
I'm going from Redhat 7.3 which is pre-thread technology to CentOS 4 on much faster hardware so I bet it will be faster than before even with the degradation you get from using threads.
After the manual install of perl-no-threads, Virtualmin came up fine when I re-installed the modules.
So you were right, :-) it was a perl module problem.
Maybe
Crypt::SSLeay ?
I'm not sure which one/ones did the trick.
I made a list of modules that were present with a virgin CentOS/virtualmin install and after installing perl (no threads please) from source, I went through and installed all the modules by hand using perl -MCPAN -e shell
Not sure why the perl I installed from source doesn't just use the modules that were already there. Call me a noob.
The funny thing is... although Vrtualmin works flawlessly again after the modules were re-installed, Interchange had problems with the Non-Threaded perl so I apparently messed up somewhere or somthing has changed under Redhat Enterprize since that howto was written.
Here is the list of modules for a virgin CentOS/Virtualmin install
Bundle::DBD::mysql
Bundle::LWP
Bundle::Net::LDAP
Convert::ASN1
Crypt::SSLeay
Data::Grove
Date::Manip
DBD::Pg
DBI
Digest::HMAC
Digest::SHA1
Filter::Util::Call
HTML::Parser
HTML::Tagset
mod_perl
Net::DNS
Net::SSLeay
Newt
Parse::Yapp
Time::HiRes
URI
XML::Dumper
XML::Encoding
XML::Grove
XML::LibXML
XML::LibXML::Common
XML::NamespaceSupport
XML::Parser
XML::SAX
XML::Twig
Anyway, if I get it working under non-threaded perl I'll post the results and howto.
It would have been nice if vermonster would have finished his howto.
Since it works flawlessly under a Virtualmin/CentOS/standard threaded-perl I'm just going to live like brute force Billie Gates for now and not worry about the 30% speed increase through optimizing, I'm just going to throw faster hardware at it :-)
John Wolgamot
<i>Since it works flawlessly under a Virtualmin/CentOS/standard threaded-perl I'm just going to live like brute force Billie Gates for now and not worry about the 30% speed increase through optimizing, I'm just going to throw faster hardware at it :-)</i>
I was just going to bite my tongue about this, but I feel exactly the same way. It's damned foolish and it makes the Interchange people look like idiots (when I'm pretty sure they actually aren't idiots). 30% compared to the hours or time wasted by countless administrators rebuilding a bunch of crap that comes standard with the OS is just ridiculous. Most commerce websites are such low load that it doesn't even begin to matter. This was one of the reasons I didn't choose Interchange for our commerce site here at Virtualmin.com...I have a hard time trusting the instincts of a development team that makes such dire pronouncements about a minor performance issue (and, if it ever was more than a performance issue, the quality of software that doesn't run safely on mainstream perl builds is questionable).
Anyway, I'm happy to hear you're sticking with the mainstream perl. You can leave the upgrades to your OS vendor and spend your time doing productive things to make your website(s) better and serving your customers better.
That said, I might end up coming back to Interchange anyway, since OpenACS is not only a bit of a nightmare, it's also written in a language that I don't know very well...whereas Interchange is in Perl, a language I know and like. ;-)
--
Check out the forum guidelines!
Yeah the threaded, non-threaded dilema has been a big thing in the interchange mailing lists.I remember reading the problems with Interchnage and threaded-perl stemed from modules that inerchange depends on more than interchange itself.Then I read them mentioning that all the modules have matured enough now that threaded-perl problems with Interchange are pretty much a thing of the past other than slower speed and higher memory usage which I guess is a normal threaded-perl side effect if you want to call it that.I agree with you that a catalog or 2 probably wouldn't see an impact but I guess I can understand if an interchange server is hosting dozens of catalogs among many users, then the non-threaded perl would seem attractive because of less memory use and speed increase.If you start playing with Interchange again Here are a few things I discovered while installng under the Virtualmin/CentOS environment.It seems better to CPAN install the following perl modules before installing interchange so the installation goes really fast.Bundle::InterchangeKitchenSinkBundle::InterchangeandSet::CronTabNote that if you do not install Set:CronTab ahead of time the make test will fail.When running makecat, I found that under virtualmin you have to answer yes to Suexec.But most importantly I found that you have to chmod the /usr/local/interchange/etc/socket to 666 or you will get a long pause and then an error when visiting the catalog.http://www.icdevgroup.org/pipermail/interchange-users/2003-September/035... you don't answer yes to the Suexec question you instantly get an error when you try to visit the catalog.Also you may have to mess with your catalog directory permissions so the server can read you catalog.cfg, as well as the permissions of directories that get created in the public_html dir too.Plus choose Multiple Group when running makecat and make sure you ad yourself and interch to your own group.Once you get it up it seems to work flawlessly under virtualmin.I really do like interchange. I don't know perl or any language for that matter but I have been able to do some pretty impressive modifications to interchange catalogs. Err... well impressive to me anyway :-)The fact is... Interchange makes it easy for even us non-programmers to do some neet things like add fields to your database, then add fileds in your catalog admin UI and it's easy to use if statements in your html to check if data exists in a database field and if it does exist then display it etc...For instance I couldn't get this girl trained to input some light blub data "consistantly" in the description field so I set it up so that each field asked questions like watts, lumens, bulb type etc... If any fields were left blank then the table wasn't even created on the page display because the "if statements" checked the database for data.[[if-item-field bulb_watts]] [tr valign="top"] [td width="9%" align="right"]Watts:[/c] [td width="2%"][sp][/c] [td width="89%"][[item-field bulb_watts]][/c] [/r] [[/if-item-field]] [[if-item-field bulb_shape]] [tr valign="top"] [td align="right"]Shape:[/c] [td][sp][/c] [td][[item-field bulb_shape]][/c] [/r] [[/if-item-field]] [[if-item-field bulb_finish]] [tr valign="top"] [td align="right"]Finish:[/c] [td][sp][/c] [td][[item-field bulb_finish]][/c] [/r] [[/if-item-field]] [[if-item-field bulb_volts]] [tr valign="top"] [td align="right"]Volts:[/c] [td][sp][/c] [td][[item-field bulb_volts]][/c] [/r] [[/if-item-field]]as seen here:http://www.liteking.com/cgi-bin/liteking/search.html?fi=products&st=... even got the quantity pricing to work pretty wellhttp://www.liteking.com/cgi-bin/liteking/quantity.html?id=ADhBaLI6&m... I got the companion items layout looking pretty good too.http://www.liteking.com/cgi-bin/liteking/P4091-55.html?id=ADhBaLI6&m... that and I don't know a line of perl.I can only imagine what an Interchange catalog would be capable of in your hands.I also use OSCommerce and I don't think I could do any of that without hard coding a bunch of php which I cannot do.I wish I could program in perl so I could really do some nifty things with Interchange.Maybe I'll get the time to learn some perl basics but for now I can at least get a store going and if I need specialized stuff there are a lot of perl programers around.
John Wolgamot