I get what Schmoozecom is trying to do, but this change doesn’t seem very well thought out. I had everything on my server force redirecting to SSL because I really don’t like the prospect of any network passwords going out in cleartext. I don’t think I’m super-paranoid in this regard, it’s pretty common security practice. So since they added the schmoozecom.conf file, or since I installed the sysadmin module, users, who were accustomed to just putting “server.yourdomain.com” in their browsers were suddenly entering passwords in cleartext. My custom redirect configuration file was being loaded after the schmoozecom.conf file.
So my quick fix was to create a file called 00schmoozecom.conf. (the numbers at the beginning are important; Apache processes the configuration files in alphabetical order) Here is a generic version of said file:
Listen 80
ServerAdmin [email protected]
DocumentRoot /
ServerName server.yourdomain.com
ServerAlias alias alias.yourdomain.local
Redirect permanent / https://server.yourdomain.com/
Listen 81
<VirtualHost *:81>
ServerAdmin [email protected]
DocumentRoot /var/www/html/recordings/
ServerName server.yourdomain.com
ServerAlias alias alias.yourdomain.local
Redirect permanent / https://server.yourdomain.com/recordings/
Listen 82
<VirtualHost *:82>
ServerAdmin [email protected]
DocumentRoot /var/www/html/aastra/
ServerName server.yourdomain.com
ServerAlias alias alias.yourdomain.local
Redirect permanent / https://server.yourdomain.com/aastra/
Listen 84
<VirtualHost *:84>
ServerAdmin [email protected]
DocumentRoot /tftpboot/
ServerName server.yourdomain.com
ServerAlias alias alias.yourdomain.local
Listen 88
<VirtualHost *:88>
ServerAdmin [email protected]
DocumentRoot /var/www/html/restapps/
ServerName server.yourdomain.com
ServerAlias alias alias.yourdomain.local
Redirect permanent / https://server.yourdomain.com/restapps/
Listen 96
<VirtualHost *:96>
ServerAdmin [email protected]
DocumentRoot /var/www/html/restapi/
ServerName server.yourdomain.com
ServerAlias alias alias.yourdomain.local
Redirect permanent / https://server.yourdomain.com/restapi/
I’m not sure if all that is necessary, but maybe Schmoozecom has some, or is planning to put some, internal links to services at those ports. If they aren’t redirected, it’ll break things. I think those redirects will cause any links to go to the correct places, and all under the same SSL certificate.
A couple important things to note, though. First, I had to create an (empty) directory at /var/www/html/aastra. I’m not sure if there’s supposed to be a folder there, or if it’s something coming in a future update, but I had none on any of my systems. (I have no aastra phones.)
Also, there are a lot of considerations depending on how you want to provision your phones. If you’re just using plain http or tftp, the configuration above should work. However, if you want to provision over https, and especially if you want to have username/password authentication (which you should) then you’ll need to do a lot more to get it to work. you’ll need to create a link to /tftpboot/ in /var/www/html/. There’s quite a bit more you’ll need to do, but that’s pretty far beyond the scope of what I’m addressing here.
Finally, if you don’t want to get errors, you’ll need to delete (or comment out) all of the directives in schmoozecom.conf. The whole reason I opted to create a new file, though, is that I don’t know when or if Schmoozecom is going to address this issue. If I just modify schmoozecom.conf, then it might get overwritten at any time. At least this way, I know if they overwrite the file, it will still preserve my redirects. (Although I’ll get harmless errors whenever httpd restarts.)
I sincerely hope that Schmoozecom addresses this. The most proper way I can think of is to include an “SSL” checkbox in the “Port Management” section of the System Admin module. This would rewrite the schmoozecom.conf file similar to the way I have it up there. Or, if their goal is increased control, they would need to put an SSL checkbox on each port, but that would require a pretty complicated SSL directive for each Virtual Host. It wouldn’t be impossible, but it would be a lot of config. If Schmoozecom is listening, SSL management would be a most excellent and useful addition to the “Sysadmin Pro” module, and in my opinion, falls just exactly under the audience you’re targeting for the commercial modules. As it is, I don’t have much use for the SysAdmin Pro module, but if it had something useful like SSL certificate management, I would buy it in a heartbeat.
Even for the poor fellas using the community only version, though, the module shouldn’t overwrite SSL redirects that are set up by users. Or at the very least, each of those options should have a checkbox to disable creation of the directive. That’s my $0.02.
