We are testing (attempting to test) Thirdlane single tenant edition for a client of ours. We have run into a fairly large roadblock in that is does not appear that there is a way to change the password for the pbxconf database and have the installer/settings updates work.
We have tried the following:
1. Just entering in a new password for root on the main installation wizard. This results in 256 errors indicating that the various sql installer scripts are unable to run.
2. We tried circumventing this problem by using the default password for the initial installation wizard (which then runs fine) and then updating all of the configuring files with a new password. When attempting to update the system settings/preferences dialog, we now get the same 256 errors for a MySQL script.
Are the scripts used in Thirdlane really hardcoded to a single username and password? If so, that is a serious security concern.
I understand your concern;
I understand your concern; however, access to the root account is limited to the localhost in MySQL and is firewalled as well. This does not solve the "root" of your concern, but it does go a long way to mitigate it.
We are a new TL consumer as well, and I am sure someone will be along with more knowledge soon.
(To be honest, I am interested in the full answer as well.)
In addition to changing the
In addition to changing the Asterisk configuration files, the password also needs to be updated in /etc/odbc.ini. In the CLI, issue the following command to verify: module reload res_odbc.so
You should see successful connection messages.
Also the password is in the following: /etc/webmin/miniserv.conf, /etc/webmin/asterisk/config.yml, and /etc/asterisk/instances.txt
Restart webmin
I understand the firewalling
I understand the firewalling and the restrictions that are put in place on the MySQL by default. However, the requirements this particular customer has for security (that is customer audited) requires substantially more password security than the default and it requires passwords to not be the default for any application in use by the organization.
Chris, I updated all of the files you mentioned EXCEPT the odbc.ini file. I am going to go through and try it again and will change them all including that file this time around.
As an update to this...
As an update to this...
Updating the password in the odbc.ini file does allow most functionality to work, however, when attempting to update the system settings page, a 256 error is still thrown just like at installation because a sql script needs to run. This occurs when clicking save whether or not any changes were made that required any db changes.
Granted the settings can be changed manually by modifying the instances.txt file, however, I think this should be looked into as a serious consideration to be updated for security purposes and ease of use.
IMHO, having only locat
IMHO, having only locat database access and a firewall is sufficient - i.e. if someone gets access to the box they can obtain database password from any of the configuration files anyway - whether it is a default password or not. That said, I will discuss this further with the team to see if we could and should do anything to secure this further.
Alex,
Alex,
The thinking that simply restricting access to the local server is a bit short sighted as it assumes that every company wants every type of Linux administer to have access to the MySQL database.
For example, say if we want to configure a lower level helpdesk employee to have access to ssh into the Thirdlane/Asterisk server to view Asterisk debug output in the event there is a problem. We would create the user and configure a sudo rule to only allow "asterisk -rvvvvv" to be run at a privileged level. Everything works great, except the "mysql" command line program can still be run by this user using "mysql -u root -p" and with the default password as the only available password that can be used (or at least supported by Thirdlane), providing any type of SSH access to any lower level helpdesk employees essentially would provide root level access to MySQL because the root DB password would be known to the world.
FYI (mostly for Chris who
FYI (mostly for Chris who seems to be using a more secure PW)...
Do not update to the latest Thirdlane without reverting everything back to the default password before doing a yum update. There are some Sql DB changes with the update it appears that are hard codes. After updating, I am getting sql errors on basically every screen.
As an update, nothing works if the password is changed.
Creating extensions, routes, etc all fail with a server error -1 if the username/password is anything other than the default.