Is there is a tool that can provide me a maximum of information (such as cpu, disk I/O, network, nfsd, memory and more) about my Linux/Unix server in a minimum of space in a terminal?
…..
Say hello to Glances
From the project home page:
Glances is a free (LGPL) cross-platform curses-based monitoring tool which aims to present a maximum of information in a minimum of space, ideally to fit in a classical 80×24 terminal or higher to have additionnal information. Glances can adapt dynamically the displayed information depending on the terminal size. It can also work in a client/server mode for remote monitoring.
If you are running a RPM-compatible version of Linux that uses YUM to install software, this is for you:
Yesterday, I had a situation where a colleague experienced an issue that caused loss of audio and it seems that one of the updates which had just finished installing may have been the culprit.
Here’s where YUM shines bright and I thought I’d share a feature with you that will definitely be of help at some point. It’s the yum history feature.
It just so happens that yum while performing updates is simultaneously running a journal transaction set recording your update to a transaction id along with all of the excruciatingly painful package update and dependency information you’d ever want to know. Most of the time, you’ll never care about it. In some situations however, you may encounter a post-update problem.
The good news with yum is you have a recourse. If you need to or at the direction of your Distro’s technical support team, you may be called upon to perform a rollback.
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.
It appears there is a nasty bug in certain versions of PHP (almost certainly in version 5.3.3, and perhaps other versions as well) that can cause SOME inbound and outbound routes in FreePBX to be ignored. Add this to the list of difficulties to plague some FreePBX users, but for once it’s not something the FreePBX developers did.
The symptom appears to be that you have an inbound route with a DID that starts with the number “2”, or an Asterisk Phonebook entry that starts with a “2”, but it doesn’t work as expected or gets changed to a negative number. Not all patterns starting with “2” appear to be affected, but ten digit numbers in certain area codes (such as 248 here in Michigan) definitely are. In the case of inbound routes, it appears that the numbers get stored in the MySQL database correctly, but when they get written out to extensions_additional.conf (the dialplan file that F—PBX generates for Asterisk to use) they get transformed into negative numbers. Therefore, when a call comes in on that DID, Asterisk doesn’t recognize it and the call gets dropped (or if you accept calls for any DID then it’s handled as such a call, but a warning message is posted to the CLI and the log file).
For a discussion of this issue, see these threads in the PBX in a Flash forum:
Just wanted to alert you to this in case you happen to have the buggy PHP version and things just aren’t working as they should be. The best fix is probably to upgrade PHP to a later version but that can cause other issues, or you may encounter unmet dependencies when trying to upgrade (in fact, if you come across a foolproof way to upgrade PHP on Centos, please let us know). If you are using PBX in a Flash, they’re aware of the issue and one would hope they’ll have a fix real soon now. If you are using any other FreePBX-based distro then you will have to bug the distributors of that distro for a fix. If you rolled your own, then good luck to you in upgrading PHP!
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.
This article was originally published in August, 2011 and may contain outdated information.
Image via Wikipedia
I just spent an interesting couple of hours trying to install phpMyAdmin on an Asterisk server running CentOS 5.5. As I encountered each problem and solved it, I had to wade through a lot of pages that weren’t applicable to my installation, etc. Since many readers of this blog run similar configurations I thought I’d just list the hiccups I encountered, and what I had to do to solve them. Note that some distributions come with phpMyAdmin already installed, so make sure you don’t already have it before you try to install it!
NOTE: Think carefully about whether you really want to follow the instructions below, particularly if it requires adding a repository. If you do that, make sure you only install the software you actually need from that repository, then disable it (set enabled=0). If you don’t do that, you could easily get into a situation where some of your curent software (such as PHP) simply will not upgrade no matter what you do. And if you are running a PBX “install and go” distribution, they may specifically warn you not to add repositories, or it will break your installation, so don’t do it!
If you do anything suggested below, you do it at your own risk!
• yum install phpmyadmin doesn’t work — try using the dag repository — there are several pages on the Web that tell how to do this. Use Google to search for “how to enable the dag repository” (without the quotes) if you need help. The basic idea is you need to create a file called /etc/yum.repos.d/dag.repo (with the proper permissions, ownership, etc.) and put something like this inside:
[dag]
name=Dag RPM Repository for Red Hat Enterprise Linux
baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag
gpgcheck=1
enabled=1
BUT you also need to install a GPG key, and getting THAT can be a bit of a problem. Some instructions will tell you to do this:
I’m being a bit non-specific because the instructions could change, and I’d prefer you find a current reference on how to enable this repository. Also, some may prefer to install RPMforge, which is a collaboration of Dag and other packagers. Regardless of the effort involved, I do suggest you install phpMyAdmin using yum, because it will install everything in the correct locations for CentOS, and you don’t have to compile it or anything like that.
Note that when you do install phpMyAdmin using yum, it may also install required dependencies such as libmcrypt and php-mcrypt (another advantage to using yum).
• You don’t have permission to access /phpmyadmin/ on this server.
Go to /etc/httpd/conf.d/phpmyadmin.conf
Under the line: Allow from 127.0.0.1
You could add a line to allow access from your local network, for example: Allow from 192.168.0.0/255.255.255.0
(But use values appropriate to your network).
If you are accessing the box remotely, then add a line allowing access from your IP address. Be VERY careful, because you don’t want to let the entire world into your databases!
• Existing configuration file (./config.inc.php) is not readable.
If you’re doing this on a system running FreePBX, scroll down to where I discuss changing the ownership of all phpMyAdmin-related files and directories to be the same as the MySQL user. Otherwise, the easiest solution (though not necessarily the most secure) is to change the permissions of the file /usr/share/phpmyadmin/config.inc.php from the default of 640 to 644 (add user read permission). If no one can get to your system from outside your local network, this probably isn’t an issue, but if anyone has a better idea on this, feel free to leave a comment.
• “Error
The configuration file now needs a secret passphrase (blowfish_secret).”
Open /usr/share/phpmyadmin/config.inc.php and find this section:
* This is needed for cookie based authentication to encrypt password in
* cookie
*/
$cfg[‘blowfish_secret’] = ‘oh my this is such a wonderful passphrase‘; /* YOU MUST FILL IN THIS FOR COOKIE AUTH! */
Insert any phrase you like (within reason) between the second pair of single quotes in the last line shown above (but don’t use ‘oh my this is such a wonderful passphrase‘, I just inserted that as an example. Be creative!). Don’t worry, this isn’t something you’ll actually have to type in every time you want to use phpMyAdmin.
• #1045 – Access denied for user ‘root’@’localhost’ (using password: YES)
You don’t login as root, you use your MySQL username and password. In FreePBX-based systems these can be found in /etc/amportal.conf, in the AMPDBUSER and AMPDBPASS settings. BUT… if you enter a wrong user name before logging in correctly, it may have already set a cookie with that username and password and then you won’t be able to get in even if you DO use the correct username and password. The solution is to clear all browser cookies for the address of your server, then try again — and make sure you get it right this time! 😉
I will note here that you can avoid some of these cookie-related issues, probably including those mentioned above, by going into /usr/share/phpmyadmin/config.inc.php and finding this section:
/* Authentication type */ $cfg[‘Servers’][$i][‘auth_type’] = ‘cookie’;
If your system is behind a hardware firewall or is otherwise VERY secure, you could change the auth_type from ‘cookie’ to something else, such as ‘http’. This will save you a lot of frustration during the login process, but at the possible expense of making your database less secure. For those concerned about security, a document on the phpMyAdmin wiki advises you to “See the page on Security or the multi–user sub–section of the FAQ for additional information, especially FAQ 4.4.” I personally found their security documentation rather useless, because they make a lot of suggestions but provide no specific examples of how to implement those suggestions. Anyway, I personally feel that as long as a system is behind a good firewall that doesn’t permit anyone on the “outside” to access phpMyAdmin, ‘http’ is a good compromise between a security model that might drive you crazy (‘cookie’) and one of the other models that’s fairly insecure, such as ‘config’ (which some consider insecure because it stores your server username and password in plain text). However, if your system is otherwise VERY secure and you just don’t want to have to enter a password to use phpMyAdmin, then it is possible to change the ‘auth_type’ to ‘config’ and (in the same config file), look for these lines:
Change mysqluser and mysqlpassword to the correct vales for your system (on a FreePBX-based system, these are the values in /etc/amportal.conf mentioned above). I do not recommend using ‘config’ because it is less secure (be sure to read the page on Security mentioned above), but it’s up to you to decide how secure you want your system to be.
(I’m fully aware that any objections to storing the user and password values in plain text in the phpMyAdmin config.inc.php fall a bit flat when you realize the same values are stored in plain text in amportal.conf, but I also feel as though the fewer places those values are exposed, the better. Why give potential attackers one more place to find this information?)
• phpMyAdmin – Error
Cannot start session without errors, please check errors given in your PHP and/or webserver log file and configure your PHP installation properly.
Check your /var/log/httpd/error_log – in my case, the first error message of each set contained a phrase like “open(/var/lib/php/session/sess_somerandomstring, O_RDWR) failed: Permission denied (13)” and I figured that the problem was another permissions issue.
On some sites I have found a suggestion that you change the ownership of all phpMyAdmin-related files and directories to be the same as the MySQL user (in the case of an Asterisk/FreePBX system, that would be asterisk:asterisk). On a FreePBX-based system, you could try this (check to make sure these are the correct paths before doing this):
If that doesn’t resolve the issue (or you’re doing this on a system that’s not running FreePBX), perhaps the easiest solution (though not necessarily the most secure) is to change the permissions of the offending file. If you have the same issue I had, try changing the permissions of the directory /var/lib/php/session from the default of 770 to 777 (add full user permissions).
Strangely, this one didn’t show up until after I’d successfully run phpMyAdmin a few times. Go figure. Also, after fixing this, I had to delete cookies again (as mentioned in the previous item) before I could log in, but that was when I still had the ‘auth_type’ set to ‘cookie’ (another reason I decided to change that to ‘http’).
Found and solved any other “gotchas” while installing phpMyAdmin under CentOS? Think I could have solved a problem in a better way? Feel free to share your solutions in the comments.
EDIT: There is one other thing that can happen after you install or update PHP on your system (as might happen if you let a FreePBX-based distribution do an upgrade). You may start seeing PHP warning messages such as:
PHP Warning: PHP Startup: mcrypt: Unable to initialize module Module compiled with module API=20050922, debug=0, thread-safety=0 PHP compiled with module API=20060613, debug=0, thread-safety=0 These options need to match in Unknown on line 0
If that happens try updating the dependencies that came with phpMyAdmin, for example:
yum update libmcrypt
yum update php-mcrypt
It was the second of those two that vanquished the PHP warning messages for me.
And why did I NEED to install phpMyAdmin, you ask? Well, because someone (ahem) made a slight configuration error and caused an endless loop, that within the space of about ten seconds or so, generated over a THOUSAND bogus records in the ‘asteriskcdr’ (Call Detail) database. The only easy way to I knew of at the time to clean them out was phpMyAdmin (since I don’t “speak” MySQL), but I don’t recommend you attempt something like that unless you know what you’re doing, because one wrong move and you could delete your entire FreePBX database (trust me, that would be a VERY bad thing!). In retrospect I probably could have used Webmin, since it also has the ability to access the MySQL database, but I didn’t think of that at the time.
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.
Here’s an article that will be helpful to may of you who are running PBX servers under CentOS, especially (but not limited to) those running on virtual machines with low disk storage space. Note that if you installed from an “all-in-one” distribution ISO, this possibly might already be installed, but may still need to be configured.
One thing you definitely don’t want to happen to your server is for it to run out of disk space, especially the root partition.
There are lots of pieces of open source monitoring software, a popular one being monit.
Below is a quick guide to installing monit and generating alert e-mails for disk space and cpu/memory usage. The installation was done on a SysAdminMan VPS running CentOS 5.5
The instructions should work for any system running CentOS 5.5. You might be tempted to take a shortcut and just do “yum install monit” but please be aware that (at least as of the day I’m writing this) it will get you a much older version of the software, so I suggest you stick with the instructions in the article. I have just now installed this on one system and have not fully tested it, but it did send an e-mail confirming that it had started.
This is just another tool you can use to make your life a little easier and help you avoid a problem before it becomes a major headache!
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.
Image by mattbraga via Flickr
Many of us face the problem of having a server that we know we should backup frequently, but we don’t do it because it’s either too difficult to figure out how, or the backup solutions offered don’t actually restore the entire system if it crashes, so we figure, “why bother?” If your system crashes, the thing you really need is a way to restore the entire system from some recent point in time.
Well, here’s one possible solution for you, assuming your server runs some form of Linux, and it’s from the fine folks at Sunshine Networks in Brisbane, Australia. I refer you to their article:
Now, don’t let the title throw you – there’s nothing Elastix-specific in this article. The instructions should work with just about anything running under the CentOS operating system, and with minor tweaks to the installation process, under other versions of Linux. What this software is supposed to do is give you an ISO file that can be burned to CD’s or DVD’s, or stored on a network share on another machine. If the worst happens, you fix the hardware problems and then reinstall from the ISO file, and the way it’s supposed to work is that you get back to exactly where you were at the time of the last backup. Now, I haven’t personally ever had to attempt a restore, but apparently others have and consider this a great piece of software. Obviously, I’m not making any guarantees, but it’s got to be better than no backup at all, right?
EDIT: Since I originally wrote this article, I’ve actually had the opportunity to use MondoRescue to restore a failed system (in this particular case, one that runs on a virtual machine). To say it worked great is an understatement. You just boot from the .iso file and it installs EVERYTHING back as it was. The only issue I had was that it couldn’t communicate with the network because the name of the network adapter was apparently different on the original and new systems — once I reconfigured the network settings to select a valid adapter (eth0, for example) it appeared to work just as it had on the day of the backup. And the restore process was surprisingly fast (much faster than the original installation, in fact)! Of course I cannot guarantee it will work that well for you, but I was blown away by the speed of the restoration, and I’m not that easily impressed!
I must also note that the article on the original Sunshine Networks site seems to have disappeared, so I changed the link to point to an archived copy on the Wayback Machine. However, in case that fails at some point, here is how I installed MondoRescue. Their instructions gave three different ways to do it, and I used this one, which (with perhaps a change in the file used) should work on any Red Hat or Centos based system (this was noted as “Tested on Elastix 2.0 32-bit” — if you are running something else, don’t just follow these instructions because you may need a different file):
cd /root/
wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.1-1.el5.rf.i386.rpm
rpm -Uhv rpmforge-release-0.5.1-1.el5.rf.i386.rpm
yum install mondo
after mondo installed correctly, you should disable the RPMForge repository, just to be on the safe side :
nano /etc/yum.repos.d/rpmforge.repo
change “enabled = 1” to “enabled = 0”
(They used vi to edit the repository; I changed it to nano. Use whichever text editor you like).
However, the file shown here is probably NOT the right one for your system. So, first go to http://packages.sw.be/rpmforge-release/ and read the descriptions for each file, and be careful to select the right one for your system, and substitute that filename in the two lines where it is used above.
After installation, you can start the program by running /usr/sbin/mondoarchive, which will bring up a GUI (of sorts). The original article notes that:
your full iso will ( under default settings ) be created in the following directory :
/var/cache/mondo/mondorescue-1.iso
there is a small recovery CD here :
/var/cache/mindi/mondorescue.iso
END OF EDIT.
The article has you use the mondoarchive GUI to make the backups (well, they actually say mondorescue, but when I downloaded the software the program was called mondoarchive), and that’s fine to start with. But eventually, you’re going to want to automate the process so you can use it in a cron job to do unattended scheduled backups on a regular basis. I have this running on one machine and send copies of the backups to another, like this (cut and paste from this article to get the full lines without wrapping) :
#!/bin/bash
mondoarchive -OVi -d "/var/cache/mondo" -E "/asterisk_backup" -N -9 -G -s 4G
ssh myaccount@server2.net rm /home/myaccount/server1backup/mondo/mondorescue-1-old.iso
ssh myaccount@server2.net mv /home/myaccount/server1backup/mondo/mondorescue-1.iso /home/myaccount/server1backup/mondo/mondorescue-1-old.iso
scp /var/cache/mondo/mondorescue-1.iso myaccount@server2.net:~/server1backup/mondo
ssh myaccount@server2.net rm /home/myaccount/server1backup/mindi/mondorescue-old.iso
ssh myaccount@server2.net mv /home/myaccount/server1backup/mindi/mondorescue.iso /home/myaccount/server1backup/mindi/mondorescue-old.iso
scp /var/cache/mindi/mondorescue.iso myaccount@server2.net:~/server1backup/mindi
The first line calls the mondoarchive program to create the backup – the -E argument excludes any directories you don’t wish to back up (I have a directory of backups made using another method that I didn’t want backed up) and you can read about the other arguments in the documentation (also see the full HOWTO). The remaining lines connect to the external server and delete the oldest backups, rename the previous backup, and then copy the new backups over. To do it the way I’ve done it here, you must have ssh access to the other server and you must be able to connect without using a password, using public/private key authentication. You may also have to log into the remote server and create the directories (/home/myaccount/server1backup/mindi/ and /home/myaccount/server1backup/mindi/ in this example – obviously you can call the directories whatever you wish, it’s entirely up to you).
There is, of course, more than one way to remove the pelt from a deceased feline, and you’ll probably have your own method for moving the files to another server. In some situations it appears that MondoRescue could do it for you (look at the n option), but it doesn’t include a provision to remove the oldest file and rename the previous one (not that I could see, anyway), so that’s why I did it in a shell script.
The folks at Sunshine Networks have several other great how-tos – you might want to give them a look! And for more useful information on MondoRescue, particularly how to perform a restore, see Configure IT Quick: Use Mondo Rescue to back up Linux servers (but please realize that article was written in 2003, and the install has apparently been made less complicated since then, so don’t use their installation instructions).
Recent Comments