Schmoozecom.conf error after restoring from backups

Hi

After restoring from a backup we couldn’t access the web interface. It appeared that httpd wasn’t loaded. When we went to start it we got these errors;


[[email protected] conf.d]# /etc/init.d/httpd start
Starting httpd: [Mon Feb 10 19:15:06 2014] [warn] module rewrite_module is already loaded, skipping
Warning: DocumentRoot [/var/www/html/aastra/] does not exist
Warning: DocumentRoot [/var/www/html/restapps/] does not exist
Warning: DocumentRoot [/var/www/html/restapi/] does not exist
[Mon Feb 10 19:15:06 2014] [warn] default VirtualHost overlap on port 82, the first has precedence
[Mon Feb 10 19:15:06 2014] [warn] default VirtualHost overlap on port 81, the first has precedence
(98)Address already in use: make_sock: could not bind to address [::]:82
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs
[FAILED]


In the end we moved schmoozecom.conf out of /etc/httpd/conf.d and httpd started fine but now we dont have the /recordings site and few other bits.

Any ideas why this may have happened and how we can resolve it?

Olly

Why didn’t you just fix schmoozecom.conf

Because I didn’t know how. That’s why I’m posting here.

Anyone got any ideas how to resolve these errors?

Olly

Olly. Post the file here and I will show you what to remove. It’s quite easy.

I ran yum update and suddenly this is borked. I’ve been running the update scripts, but this is what ended up in my schmoozecom.conf:

Listen 81
<VirtualHost *:81>
DocumentRoot /var/www/html/aastra/

Listen 82
<VirtualHost *:82>
DocumentRoot /var/www/html/restapps/

Listen 83
<VirtualHost *:83>
DocumentRoot /var/www/html/restapi/

Listen 82
<VirtualHost *:82>
DocumentRoot /var/www/html/recordings/

Listen 80
<VirtualHost *:80>
DocumentRoot /var/www/html/

Listen 81
<VirtualHost *:81>
DocumentRoot /tftpboot/


Which of the 81s/82s are bad?

Just so it’s clear, commenting out the second “Listen 81” and “Listen 82” will fix the port binding error and Apache will start. The first virtualhost on the ports gets precedence, so that doesn’t fix the whole problem unless, by chance, the second of each of the 81,82 VHosts are the wrong ones.

Strange that Apache can take precedence on the virtualhosts but can’t figure out that a second Listen on the same port will bring problems, but that’s for a different forum.

If we comment out the first 81 and 82 sections does that mean we dont need access to /var/www/html/restapps/ and /var/www/html/aastra/ ?

Does this need a bug fix?

If you think it needs a bug fix then report it. don’t ask for permission

Hi tm1000,

My quick method of resolving the problem was to simply add the folders that don’t exist like /var/www/html/aastra/, however what was the suggested change to the schmooze.conf file?
This is in respect to the missing files warning which allows you to load apache, but sends you an email each time because of the warning.
The port of course is the simple change.

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.

Craig, have you opened feature request or tickets on this?

I have now. :slight_smile:

http://issues.freepbx.org/browse/FPBXDISTRO-101