These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for Virtualmin and AWBS hosting software on the new forum.
Web Hosting and Cloud Computing Control Panels
Perhaps this might help, Jamie??
I get this error on the AWBS side when trying to setup a new user with a clone of the default template.
Unknown option webmaster@solvnethosting.comAdds a new Virtualmin virtual server, with the settings and featuresspecified on the command line.usage: create-domain.pl --domain domain.name --pass password-for-unix-user [[--parent domain.name | --alias domain.name]] [[--desc description-for-domain]] [[--email contact-email]] [[--user new-unix-user]] [[--dir]] [[--unix]] [[--mail]] [[--dns]] [[--web]] [[--webalizer]] [[--ssl]] [[--logrotate]] [[--mysql]] [[--ftp]] [[--spam]] [[--virus]] [[--status]] [[--webmin]] [[--virtualmin-dav]] [[--virtualmin-awstats]] [[--virtualmin-mailman]] [[--allocate-ip]] | [[--ip virtual.ip.address]] [[--ip-already]] [[--max-doms domains|*]] [[--max-aliasdoms domains]] [[--max-realdoms domains]] [[--max-mailboxes boxes]] [[--max-dbs databases]] [[--max-aliases aliases]] --quota quota-for-domain]] --uquota quota-for-unix-user]] [[--template "name"]] [[--prefix username-prefix]] [[--db database-name]] [[--fwdto email-address]] [[--reseller name]]Exit status: 256
Hi Joe,
I finally got AWBS to work with VirtualminPro, kind of.
They finally have selection for all the current options, but when I select to enable AW stats (or DAV) they don't get enabled on install. Is this our end our their problem?
Hey Dan,
It might be our problem. To test try creating a domain using the command line script with those options enabled. If that sounds scary, I'll poke at it here. The command line and remote API haven't gotten a lot of use yet, so bugs very well could exist unknown to any of us.
--
Check out the forum guidelines!
That's what I thought. They have gotten a little better on their end, the 3rd party scripts install now too. That reminds me, Joomla fails on install regardless if it's in Virtualmin or the AWBS. Not a biggy, it was just a 3rd party script test that I thought I would throw out to clients.
You guys are awesome!!!
Hey Dan,
Thanks for the vote of encouragement. We're trying our darnedest to do things Right rather than just Right Now (though we're also going as fast as we can). I'm in the midst of a huge update to the Install Scripts feature. Someone noted several older versions in the forums, and so I'm going through every single one: updating to the latest, testing the install, verifying that everything shakes out as it should...and also making some notes on how to improve things in the future. Right now, some scripts require additional configuration after installation, and I'm working on ways to get around that by configuring it directly during installation. Usually we have enough information, and if we don't we can gather it in the install form. This is a pretty popular feature, so it's going to get a lot of attention going forward...it's just a huge amount of work!
Feel free to file bugs about anything that doesn't work right in the command line scripts. Jamie will get it knocked out fast, if he knows it's broken.
--
Check out the forum guidelines!
According to AWBS, this is what's going on:
>>The problem is either apache2 + curl related, or the way virtualmin configures/compiles/installs componants. All curl calls to the vm api placed over apache2 + curl from a virtualmin server time out at 30 seconds, regardless of php.ini and apache.conf timeout settings. We are looking at a resolve to this, but have not found the answer yet. Any calls to the api that are under 30 seconds to completion will work.
Hi Joe,
When I was reading up on cURL I note the option:
-m/--max-time[seconds>
Maximum time in seconds that you allow the whole operation to take. This is useful for preventing your batch jobs from hanging for hours due to slow networks or links going down.
When I tried to check the default setting (to see if it's 30 seconds) I couldn't find the default config:
~/.curlrc
Default config file.
Is that more RH magic in centOS 3.7 that can't be adjusted???
Hey Dan,
<i>Is that more RH magic in centOS 3.7 that can't be adjusted???</i>
I'm not aware of <i>any</i> magic in CentOS 3.7 that can't be adjusted. Everything that can be adjusted on any other Linux variant can be adjusted on CentOS, though it might not be done in the same place as another Linux distro.
Curl, however, uses the same config file location. That said, it could be that when curl is called as a library (as I assume AWBS is doing) it doesn't respect the .curlrc. I'm really not sure. Could I login to your system to see these timeout problems occurring for myself? (Email me with details if that is possible.)
--
Check out the forum guidelines!
Hi Joe,
The point I was trying to make was that I can't find curlrc. THe only thing I can find is the binary, curl, nothing I could find to check settings.
I took the awbs off but I can reinstall it on another box without an SSL IP. I'll need a couple hours to get it up.
Hi Joe,
Did you get my email with login?
Everytime you ask me and I try to email you back virtualmin.com sends it back as unknown user.
Hey Dan,
I got it. Just haven't had a chance to act on it.
Yeah, I haven't figured out how to get the OpenACS "respond via email" stuff working...though I'm surprised you got an unknown user bounce. That wasn't happening when I was last testing it. Something has gone even more wrong with the configuration. ;-)
I'll have a look at your box today, and see if I can figure out why AWBS is timing out. They'll have to be the ones to fix the problem, but I might be able to help them figure out what's causing it.
--
Check out the forum guidelines!
just got this back from awbs in response to what you emailed me:
We are using the curl compiled into php, not the command line version. As AWBS is just a php script running via the web server, it runs as told. If phpsuexec is compiled, then AWBS (as well as any other php script run) runs as the directory owner, else it runs as the same user as the webserver (usually nobody).
Our crons are simply calling php curl commands via the php apache module.
All aspects of php in this environment is usually controlled by what resides in the system php.ini.
The problem is, no matter what is used in the php.ini for max_execution time, no matter what is set in httpd.conf for timeout values, all calls made to VM from AWBS (when AWBS is running on the same server as VM) timeout at 30 seconds, every time. Yet, if I install AWBS on a cpanel server and connect to VM running on a remote server, all calls run as expected without any issues.
We are still working on this issue. Any insight the VM staff can offer is welcome.
I'm adding the note that I also installed awbs on it's own box controlled by VM and centOS and called VM remotely giving the same results I've always gotten, even when awbs is given it's own IP address.
more from the awbs board:
Steve, although you use curl, does VM need a get or post request?
As some servers use a get request to process everything, you may be able to get something like fopen or file_get_contence to run instead of curl when it comes to VM as that should obey a different set of rules.
I am also assuming that you have used the curl_setopt to set the time out also.
Really, i dont see how this can be an apache2 issue, it seems more like an issue with the way curl and/or php is compiled, as apache 2 isnt really sending the requests, its just delivering the pages to the visitor. Also if its running on a cron, apache (unless using wget/lynx to run the cron) isnt even involved, as it runs the CLI version of PHP. Again this could be the problem, if there are multipul instances of PHP its possiable that they both read different PHP.ini files when running the cron.