Can't add virtual servers in IE7 (OK in FireFox)

Virtualmin
1

I’m setting up Virtualmin 3.61.gpl on a dedicated RHEL 5 server.
Quad-core Intel CPU, 4GB RAM, 32bit RHEL 5.2 OS.

I’ve used the wbm-virtual-server-3.61.gpl-1 RPM to install virtualmin. We have about 100 domains (plus a few “alias domains” for some of those) and a little under 2000 email users to host. This is a (manual) migration from an older FreeBSD server.

Virtualmin has been working fine in testing, but now we have hit a strange snag while adding domains (virtual servers, in Virtualmin-terminology – they are not really virtualized servers a la VMware or similar). In IE7, the "Add new virtualserver, owned by" button in the main /virtual-server/ screen no longer works. You just get "Internet Explorer cannot display the webpage" error message instead.

It seems that the generated URL for the form is too long, or something? The URL includes d=123456789& for each virtual server already created, which seems extravagant?

It works OK in Firefox, so it’s not a showstopper at this point… but it is unfortunate, and seems odd behaviour. Can anyone confirm some sort of limit to the size of the URLs IE7 can handle, or other reason why this is happening? Is there a known workaround? Should this be switched from a GET to a POST? Does the Pro version somehow avoid this issue? Other than reading the domain_form.cgi code (which I have started to do!), where else should I be looking for documentation at this low level of detail?

We current have about 62 domains (virtual servers) added.

Thanks in advance,

Jonathan

The URL (IP changed to 192.168.1.1) generated by that button is now:

https://192.168.1.1:10000/virtual-server/domain_form.cgi?d=122272592229433&d=12224640681589&d=122245804710509&d=122246525815119&d=1222726898590&d=122246382732056&d=122272543127901&d=1222463982766&d=122272502725590&d=12224646998192&d=12227270001435&d=12227270561841&d=122272462224339&d=12224643785461&d=12224648599932&d=12227271722538&d=122272537527171&d=122272529726875&d=122245960115592&d=12224645526607&d=122245829611935&d=122246501411558&d=12227271612359&d=12224642984369&d=12224646467718&d=122272619730492&d=122246527415468&d=122246513413233&d=122272518226115&d=12224641552807&d=122246493210715&d=122272258417359&d=122246338130506&d=1222726918783&d=122272519926289&d=122272405121956&d=122246388132466&d=122246522214716&d=1222463974468&d=122246061922197&d=122272473324676&d=12224648289556&d=12227272293433&d=122272632931074&d=122245982217241&d=122246033320377&d=12224640201196&d=122272525726669&d=122246556817693&d=122246026619675&d=122272460924154&d=122272434923274&d=122246021719248&d=122245129425827&d=122272276818136&d=122272310519464&d=12227272153078&d=122246505512103&d=12224646107052&d=12205009149468&d=12224643325069&d=122246509312812&d=12227271992868&d=122272651731514&d=122246489510316&d=122246040621116&d=122272398621701&d=122246085123043&d=12227271022080&d=12224646237361&d=122272239016606&d=12224647488746&d=12227273153899&d=12224642473944&d=122272580929077&d=122247612811922&d=12227272703671&d=122246130224722&d=122272676932711&d=122245966416075&d=122246520414369&d=122246539616577&d=122245825711569&d=122272479624935&d=122272540027359&d=122272524226502&d=12224641212267&d=12224641142006&d=122272455623920&d=122245977816857&d=122246016418859&d=122245971716462&d=122272541527529&d=122246529315848&d=122272413722490&d=12224642113506&d=122246009618397&d=122246549217105&d=122245955815233&d=122246097423572&d=122246058721845&d=122246517213947&d=122245989017650&d=122272409322229&d=122246030020019&d=122246037220748&d=122272600929865&d=12224642974368&d=122246513113197&d=12224578639794&d=12224642023207&d=122246506012250&d=12227269361164&d=122272594029618&d=122246325529961&d=12224647899150&d=12227271852707&d=122107108616533&d=122272660331816&d=12227270351662&d=122245810610890&d=122246498011137&d=122272674832521&d=12224645206210&d=122272418722741&add2=Add+new+virtual+server%2C+owned+by%3A&parentuser2=

2

What theme are you using?

3

StressFree, from

http://www.stress-free.co.nz/files/theme-stressfree.tar.gz

Is that that problem?

4

I just tried switching to “Blue Framed Theme” and it didn’t make any difference as far as the “Add new virtual server, owned by” button working in IE7.

5

Virtualmin Framed Theme is the only theme that works well with Virtualmin.

I don’t know if it’s the problem in your case…but I’d try that first.

Anyway, it’s still a bug…report it in the tracker, and it’ll get fixed.

6

That theme doesn’t even display the add new virtual server button at all, even in Firefox, for me. If that’s really the only theme virtualmin works well with, it might be appropriate to make the virtualmin RPM depend on the theme RPM?

I’ll add a bug to the tracker… thanks.

7
That theme doesn't even display the add new virtual server button at all

You’re looking at it wrong. :wink:

That theme is designed for Virtualmin, explicitly, and it puts every useful function in Virtualmin into the left-hand menu. Obviously, there shouldn’t be two completely different ways to get the exact same action…so the buttons go away, and are replaced by menu items.

Theoretically, Virtualmin will work with any standard Webmin theme (and it displays the old-fashioned buttons, unless told that the Virtualmin menus will be provided elsewhere), but the ease of use and speed of use goes dramatically up if you use a theme designed for Virtualmin. And, right now, Virtualmin Framed Theme is the only theme designed for Virtualmin.

8

Worse yet: with the Virtualmin Framed Theme installed and active, the default webmin page now generates an error:

HTTP/1.0 500 Perl execution failed Server: MiniServ/0.01 Date: Tue, 30 Sep 2008 01:25:18 GMT Content-type: text/html Connection: close
Error - Perl execution failed

Undefined subroutine &virtual_server::sort_indent_domains called at /usr/libexec/webmin/virtual-server-theme/left.cgi line 89.

Which makes it hard to navigate around to put the StressFree theme back – I ended up hand-editing the config file :slight_smile: At some point I’ll see if I can duplicate this behaviour again and file it as a bug too…

9

You’re running an old version of Virtualmin without that function.

10

Oh, yeah, that should be an RPM dependency…but I guess someone forgot to bump the revision in the theme dependency list.

11

I upgraded to 3.6.2 but that won’t run, saying “The Suexec command on your system is configured to only run scripts under /var/www, but the Virtualmin base directory is /home. CGI and PHP scripts run as domain owners will not be executed.”

Lookslike suexec can’t be configured at runtime, only recompiled. Do I need to recompile the whole RHEL httpd SRPM with AP_DOC_ROOT="/home" to work around this??

12

You don’t need to compile anything – but that does mean you aren’t using the Virtualmin Apache packages. Those come with an suexec compiled for /home.

When you installed, did you by chance use the install.sh installation script (don’t run it now, it’ll just cause trouble!)?

You might want to install the Virtualmin Apache packages though, which can be found in the Virtualmin repo –

Pro: http://software.virtualmin.com

GPL: http://software.virtualmin.com/gpl/

The packages are nearly identical to those that come with your distribution, so you shouldn’t have any trouble in switching to them (that said, be sure to have backups just in case :wink:
-Eric

13

I’m uncomfortable switching to binary RPMs from the Internet for something as basic to server operation as httpd. I’ll grab the SRPM, compare its contents to the official RHEL one, and go from there. Then I’ll need to tweak the yum configuration so it won’t update httpd from the official repository, I suppose. I can do that, but it’s extra work and complexity that I didn’t realize webmin/virtualmin required.

IMO it’s pretty sad that virtualmin needs this kind of thing and can’t work with the existing distribution supplied services. Now (for example) RH will probably not support me if Apache issues crop up and I open a support request, because I am no longer using their supplied httpd RPM… if I had wanted to run Fedora or CentOS (or Debian or Ubuntu) and do 100% self-support, then I would have done that :slight_smile:

Which other packages from http://software.virtualmin.com/gpl/ are required for virtualmin to work as expected? All of them?? Is there a document available somewhere describing the changes made in each one of them compared to the distribution-supplied originals?

Thanks,

Jonathan

14
I'm uncomfortable switching to binary RPMs from the Internet for something as basic to server operation as httpd.

They are signed with my public key. If you don’t trust us to provide a build of Apache, are you sure you want to trust us with a root-level administrative tool? :wink:

I’m kidding, have at it. The SRPMS are available. I’ve documented on a few occasions the two changes I make to the Apache RPM, but they’re extremely simple:

Set suexec_docroot to /home, to make it more suitable for virtual hosting with many users (users live in /home…so that’s where we put their web data).

Set Epoch to 1 so that people trying to "upgrade" to our Apache package can do so easily.

That’s it. No other changes.

15
IMO it's pretty sad that virtualmin needs this kind of thing and can't work with the existing distribution supplied services.

Yes, it’s unfortunate. I don’t like maintaining these packages, at all. It takes about 25% of my development time. But, it’s got to be done.

But, let me ease your mind some:

If you’re running CentOS or RHEL 5, you only need our httpd packages. All of that other stuff is optional packages that customers begged us to offer (php4, for example). I do not rebuild packages arbitrarily. I hate maintaining RPMs already provided by the OS and I avoid it as much as I possibly can. So, there are no “repeats” in the CentOS/RHEL 5 repo except for http (I don’t think).

clamav is there bacause Red Hat doesn’t provide a ClamAV package, at all…if you don’t want AV scanning, then you don’t need to install it, and you won’t have that extra foreign package. But, if you want AV scanning…well, you’re going to have to get that package from somewhere, and Red Hat isn’t going to provide it. So, it might as well be from us (ours is based on the EPEL package, with a couple of tweaks to the config file to make it actually work after installation).

Likewise for ProFTPd. We provide it because Red Hat does not. You can also use vsftpd with Virtualmin, though it’s not as powerful/flexible as ProFTPd. But, if you prefer it, grab the vsftpd module for Virtualmin and enjoy. (I happen to hate FTP, in general, and don’t use it…but most people want FTP, so we support it, and provide the FTP server that most of our customers want.)

If you read a bit more on the forums and in the docs and such, I’m constantly telling people to stick with what their OS provides whenever possible. There’s no need to scold me for providing additional packages. We’re on the same side…the side that doesn’t want extra packages not provided by the OS. But, if you want a fully functional virtual hosting system, you need a few extra packages.

16

andreycheck wrote:

When you installed, did you by chance use the install.sh installation script (don't run it now, it'll just cause trouble!)?
No, I installed based mainly on a Howto at http://www.howtoforge.com/virtual-hosting-with-virtualmin-on-centos5.1

If install.sh goes around replacing distribution-provided official RPMs with its own near-equivalents (and especially if it does so without warning me it is doing that), then I’m actually glad I didn’t use it – I want to know what is going on on my servers and be able to support them when they break. I want to be able to use updates from the OS distribution vendor when security issues are found. And so on…

I want webmin/virtualmin to be a friendly and easy to use user interface for staff to add new domains, email accounts, etc. That’s what I thought it was. I don’t want webmin/virtualmin to transform my server into something I don’t understand and something that is non-standard when it comes to troubleshooting it.

Looking in http://software.virtualmin.com/gpl/rhel/5.2/i386/ I see around 15 source RPMs creating about 30 binary RPMs (16 and 44 if you include the php4-* ones, which I would think are optional)… that is rather a lot of code to read through and compare. Way more than I would have expected.

Clear documentation of why each one is necessary, and what changed, would really help. Even just a pile of .spec.diff files would be a start. If I end up making my own set of such files and or documenting what the changes are, I’ll do what I can to get them contributed back to the project, so others don’t need to do this the long way.

17

Joe wrote:

If you're running CentOS or RHEL 5, you only need our httpd packages.

That’s a relief! I was just starting to go through the set of SRPMs… A README file might be good, in there with the packages, explaining what they are for, which ones are required vs which are optional, explaining why the optional ones are present and when they might be wanted/needed?

If you read a bit more on the forums and in the docs and such, I'm constantly telling people to stick with what their OS provides whenever possible. There's no need to scold me for providing additional packages.

Additional optional ones, no problem :slight_smile: Though making it clear which are optional and which are required would definitely be good.

So VirtualMin is a one-man project? Impressive. I’d have guessed two or three developers.

But, if you want a fully functional virtual hosting system, you need a few extra packages.
Sure. I'd suggest making the virtualmin RPM depend on your modified httpd one, if it actually *needs* it... that way the dependency is clear right from the start. Or, is there some way to configure things so that all the document roots are in fact all under /var/www by default on RHEL and similar distributions, so virtualmin could avoid the need for a modified suexec (and therefore httpd RPM) entirely?? Maybe making the home directories of users that own virtual servers be under /var/www/home or something along those lines? You'd end up with email (Maildir) stored on your /var/www partition, but the current setup mixes web and email disk space under /home anyway, so no real loss there... cd ~user would still work fine of course... did you try this and something broke?

I’m tempted to move a few of these virtual servers to /var/www and see what breaks :slight_smile:

18
So VirtualMin is a one-man project? Impressive. I'd have guessed two or three developers.

Two full-time, one part-time. Jamie develops, I package and support and deal with the website and business issues, and Eric helps out with support.

19
If install.sh goes around replacing distribution-provided official RPMs with its own near-equivalents

Only httpd-* is a replacement.

As I just explained, all of the other packages are there because Red Hat does not provide them. They are not replacing OS provided packages, because the OS does not provide them. You’re making it sound like install.sh is doing something sneaky. It’s just automating a complex process and removing a lot of variables that cause trouble for folks. It is optional to run it, and it is optional to use any of our packages. If you don’t want to use our rebuild of httpd, then disable suexec and be happy (though less secure).

We provide SRPMS of everything in the repository. You don’t expect Red Hat to provide a breakdown of everything they do differently from the upstream source, do you? (You can, of course, get that information from the SRPM. Just as you can from us. We’re not hiding anything, and I’m not secretive about what happens in a Virtualmin system…Jamie and I are open source developers of over 12 and 10 years, respectively…if you don’t know who we are, it’s really easy to find out. Our “paper trail” is incredibly long and varied. In fact, I’d suggest that we’re more easily vetted than most of the folks building packages at Red Hat.)

Looking in http://software.virtualmin.com/gpl/rhel/5.2/i386/ I see around 15 source RPMs creating about 30 binary RPMs (16 and 44 if you include the php4-* ones, which I would think are optional)... that is rather a *lot* of code to read through and compare. Way more than I would have expected.

As I mentioned, only httpd is a replacement, and it is also optional. If you don’t want what the additional packages provide, then you don’t need to install our packages.

Again, you’re assuming we’re making you do stuff that we aren’t. If you only want to run RHEL packages plus Virtualmin/Webmin/Usermin, then you certainly can…but you have to disable several features to do that, because the packages provided by RHEL don’t offer those capabilities. We are infinitely flexible…but if you want it to be easy, and without a lot of effort and knowledge on your part, you have to trust us a little bit.

We only have so many hours in the day, and we’re just a couple of guys supporting 1500+ paying customers, and a few million Open Source users. We’d certainly welcome your contribution, however. The wiki is editable by any registered user…it’d be great to have more documentation about the packages and install process. My focus has been on making it so easy that it needs almost no documentation (and install.sh achieves that pretty well for most users). All of those packages are a feature. They are things customers wanted. If you don’t want them, you do not have to use them.

BTW-Don’t take this as discounting the importance of documentation. We provide over 1000 printed pages worth of documentation for Webmin in the Webmin wiki, and several hundred pages worth of Virtualmin docs in our wiki here. But, I’ve never had requests to dissect our packages in as much detail as you’ve requested, so I’ve never written any (and, again, most folks aren’t quite as suspicious of our intentions or our competence).

20

Oh, yeah, there actually is coverage of our packaging policy in the FAQ here:

http://www.virtualmin.com/faq/cat/virtualmin/68/#faq81