Koozali.org: home of the SME Server
Obsolete Releases => SME 9.x Contribs => Topic started by: Brenno on June 23, 2020, 02:50:07 PM
-
Has anyone managed to install Smokeping in an ibay? We used to have this running on a separate Ubuntu VM but I'd like to see if I can get it running on SME.
-
Not me.
At a very quick glance 'probably' but haven't checked dependencies.
Give it a go!!
Allow executable content in an ibay etc.
-
Has anyone managed to install Smokeping in an ibay?
What attracts you to smokeping? I am serious; this a straight up question.
-
What attracts you to smokeping? I am serious; this a straight up question.
I want to be able to monitor network latency over time to a handful of hosts. We have about 15 facilities connected through various ISPs using MPLS or other solutions and I'd like the ability to go back and look at historical performance data.
As I mentioned, we had it on our network before (installed and later removed by another admin) and it was great for giving us a picture of the overall network connectivity. That being said, if there's an another contrib that provides similar functionality, I'm happy to give it a look.
-
Here are my (very!) rough notes on how I set it up. Still up and running...
# 2017-07-07 Install smokeping (unsuccessful / in progress)
# more notes:
# https://www.urban-software.com/cacti-howtos/install-smokeping-on-centos-6/
#
# http://oss.oetiker.ch/smokeping/doc/smokeping_install.en.html
# http://office.mmsionline.us/smokeping
# create ibay named "smokeping"
cd /home/e-smith/files/ibays/smokeping/files
wget http://oss.oetiker.ch/smokeping/pub/smokeping-2.6.11.tar.gz
tar zxvf smokeping-2.6.11.tar.gz
cd smokeping-2.6.11
./configure --prefix=/home/e-smith/files/ibays/smokeping
# configure instructed me to run a separate command to download perl modules...
./setup/build-perl-modules.sh /home/e-smith/files/ibays/smokeping/thirdparty
# after perl modules were installed (~4 - 5 minutes)
./configure --prefix=/home/e-smith/files/ibays/smokeping
/usr/bin/gmake install
# edit /home/e-smith/files/ibays/smokeping/etc/config.dist
# set local name and appropriate email addresses
# set mail server to 'localhost'
# install fping
yum install --enablerepo=smecontribs install fping
# create missing directories
mkdir -p /home/e-smith/files/ibays/smokeping/cache
mkdir -p /home/e-smith/files/ibays/smokeping/data
mkdir -p /home/e-smith/files/ibays/smokeping/var
# set secure perms on smokeping_secrets.dist
chmod 400 /home/e-smith/files/ibays/smokeping/etc/smokeping_secrets.dist
# test configuration
cd /home/e-smith/files/ibays/smokeping
./bin/smokeping --config etc/config.dist --debug
# play around with cgi filenames and locations, html filenames and locations, cache and cropper folder locations...
# errors appearing in /var/log/httpd/error_log
# 2017-07-07 continue work on smokeping
# copy various ".dist" files
cd /home/e-smith/files/ibays/smokeping/etc
cp smokemail.dist smokemail
cp smokeping_secrets.dist smokeping_secrets
cp tmail.dist tmail
cp basepage.html.dist basepage.html
# edit config to put cache and image folders in "html" instead of "cgi-bin", use copies of files instead of ".dist" versions
imgcache = /home/e-smith/files/ibays/smokeping/html/cache
# imgurl is relative to the location of the cgi file!
imgurl = ../cache
cgiurl = https://office.mmsionline.us/smokeping/cgi-bin/smokeping.fcgi
# 2018-02-25 Smokeping Update
# download new version
cd /home/e-smith/files/ibays/smokeping/files
wget https://oss.oetiker.ch/smokeping/pub/smokeping-2.7.1.tar.gz
tar zxvf smokeping-2.7.1.tar.gz
cd smokeping-2.7.1
PERL5LIB=/home/e-smith/files/ibays/smokeping/thirdparty/lib/perl5/
export PERL5LIB
#
# copy 'setup' from 2.6.11, then update perl using
./setup/build-perl-modules.sh /home/e-smith/files/ibays/smokeping/thirdparty
#
./configure --prefix=/home/e-smith/files/ibays/smokeping
make install
-
You may also want to look at the Cacti contrib (https://wiki.contribs.org/Cacti)
learn more about Cacti: https://www.cacti.net/
-
You may also want to look at the Cacti contrib (https://wiki.contribs.org/Cacti)
learn more about Cacti: https://www.cacti.net/
I hadn't heard of Cacti before, so I tried to install it but ran into some errors with the install (opened bug 10972). Thanks for the heads-up.
-
Bug link is here.
If I or one of the other in the team get a minute we'll take a look.
https://bugs.contribs.org/show_bug.cgi?id=10972
Can you just tell us exactly what you did when you installed please?
-
I just followed the steps from the wiki (https://wiki.contribs.org/Cacti)
yum install smeserver-cacti --enablerepo=smecontribs
/etc/e-smith/events/actions/initialize-default-databases
expand-template /etc/e-smith/sql/init/80cacti
That's as far as I got. I then removed, rebooted and tried again but got the same result.
-
Additional information, in case it's helpful...
This morning I tried to remove Cacti again using:
yum remove smeserver-cacti
and then, per instructions, ran:
signal-event post-upgrade
signal-event reboot
As I watched the reboot process through the VSphere Remote Console, I noted the screen freezes on "Loading cacti into mysql". The console becomes unresponsive, but the server is running fine. I can still use putty to gain access to the server and server-manager also works.
But, I think it's interesting that on startup the system is still trying to load cacti into mysql despite me removing the contrib. The cacti_sme database was never created during the install (as noted in the bug report) so this is likely the root of the problem.
-
Sounds like the failure in the install did create a basic cacti DB but failed thereafter.
So it did this:
CREATE DATABASE $db DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
And failed later. That was the bit I was going to test.
Simple answer will be to manually remove the remnants of the DB and post-upgrade;reboot
Something like:
/usr/bin/mysql
drop database cacti_sme;
drop user cacti@localhost;
flush privileges;
I will try and take a look at this as it seems more sensible to use cacti than smokeping. Just need to find myself a bit of time.
If you want to manually force the DB creation you can probably do something like this
/usr/bin/mysql
CREATE DATABASE cacti_sme DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
use cacti_sme;
GRANT ALL PRIVILEGES ON cacti_sme.* TO cacti@localhost IDENTIFIED BY 'changeme';
use mysql;
GRANT SELECT ON `mysql`.`time_zone_name` TO 'cacti'@'localhost';
flush privileges;
-
Sounds like the failure in the install did create a basic cacti DB but failed thereafter.
So it did this:
CREATE DATABASE $db DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
And failed later. That was the bit I was going to test.
Simple answer will be to manually remove the remnants of the DB and post-upgrade;reboot
Something like:
/usr/bin/mysql
drop database cacti_sme;
drop user cacti@localhost;
flush privileges;
I will try and take a look at this as it seems more sensible to use cacti than smokeping. Just need to find myself a bit of time.
If you want to manually force the DB creation you can probably do something like this
/usr/bin/mysql
CREATE DATABASE cacti_sme DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
use cacti_sme;
GRANT ALL PRIVILEGES ON cacti_sme.* TO cacti@localhost IDENTIFIED BY 'changeme';
use mysql;
GRANT SELECT ON `mysql`.`time_zone_name` TO 'cacti'@'localhost';
flush privileges;
Have posted to the bug.
I checked an older rpm i had for this contrib and /etc/e-smith/templates/etc/e-smith/sql/init/80cact looks like this:
# cat -n 80cacti
1 {
2 my $db = $cacti{DbName} || 'cacti_sme';
3 my $user = $cacti{DbUser} || 'cacti';
4 my $pass = $cacti{DbPassword} || 'changeme';
5 $OUT .= <<END
6 #! /bin/sh
7 if [ -d /var/lib/mysql/$db ]; then
8 exit
9 fi
10 /usr/bin/mysql <<EOF
11 CREATE DATABASE $db DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
12 use $db;
13 use mysql;
14 GRANT ALL PRIVILEGES ON $db.* TO $user\@localhost
15 IDENTIFIED BY '$pass';
16 flush privileges;
17 EOF
18 /usr/bin/mysql $db < /etc/e-smith/db/configuration/migrate/80cacti_sme.sql
19 END
-
Thanks.
My guess is it is probably right but there's a syntax error or similar.
It was undoubtedly added for a reason. I need to check the spec file & changelog and see why.
-
I've updated Bug 10972 (https://bugs.contribs.org/show_bug.cgi?id=10972)
1. Install the contrib as described in the wiki
yum install smeserver-cacti --enablerepo=smecontribs
2. Create a database password
config setprop cacti DbPassword $(< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c${1:-32};echo;)
3. Create a corrected copy of the template
[edited 2020-07-04 to include the command that creates the custom template folder]
# create the custom template folder
mkdir -p /etc/e-smith/templates-custom/etc/e-smith/sql/init/
# copy and customize the default template into the custom template folder
sed -e 's/DbName/DbDatabase/' \
-e 's/\([^\]\)@/\1\\@/' \
-e 's/`mysql`.`time_zone_name`/mysql.time_zone_name/' \
-e 's|/etc/e-smith/db/configuration/migrate/80cacti_sme.sql|/usr/share/doc/cacti-1.1.19/cacti.sql|' \
/etc/e-smith/templates/etc/e-smith/sql/init/80cacti \
> /etc/e-smith/templates-custom/etc/e-smith/sql/init/80cacti
4. Re-expand the cacti db.php config to get the new password configured
expand-template /etc/cacti/db.php
5. Initialize the database
service mysql.init restart
NOTE: you need to drop the database using mysql -e "drop database cacti_sme;" if it already exists or the initialize step is skipped...
6. Reboot to update the web server
signal-event post-upgrade; signal-event reboot
This still leaves the system wanting:
* a newer version of mysql (preferred version = 5.6+)
* several other performance-related changes to the mysql config
* configuration to get it to start working
...but it seems to be up and running.
-
Thanks Mike.
I'll try & take a look.
Brian is working on migrating contribs to v10. Feel free to join in the chat in Rocket. We need help testing.
-
3. Create a corrected copy of the template
sed -e 's/DbName/DbDatabase/' \
-e 's/\([^\]\)@/\1\\@/' \
-e 's/`mysql`.`time_zone_name`/mysql.time_zone_name/' \
-e 's|/etc/e-smith/db/configuration/migrate/80cacti_sme.sql|/usr/share/doc/cacti-1.1.19/cacti.sql|' \
/etc/e-smith/templates/etc/e-smith/sql/init/80cacti \
> /etc/e-smith/templates-custom/etc/e-smith/sql/init/80cacti
I'm getting an error when I run this command:
-bash: /etc/e-smith/templates-custom/etc/e-smith/sql/init/80cacti: No such file or directory
Do you mean to use /etc/e-smith/templates/etc/sql/init? My templates-custom folder only has a /etc/php.ini folder in it.
-
Doh.
Many apologies -- looking back at the notes I have posted I see that I neglected to include a command to create the destination custom template folder first:
# create custom template destination
mkdir -p /etc/e-smith/templates-custom/etc/e-smith/sql/init/
#
# copy and customize the default template
sed -e 's/DbName/DbDatabase/' \
-e 's/\([^\]\)@/\1\\@/' \
-e 's/`mysql`.`time_zone_name`/mysql.time_zone_name/' \
-e 's|/etc/e-smith/db/configuration/migrate/80cacti_sme.sql|/usr/share/doc/cacti-1.1.19/cacti.sql|' \
/etc/e-smith/templates/etc/e-smith/sql/init/80cacti \
> /etc/e-smith/templates-custom/etc/e-smith/sql/init/80cacti
-
I've made some more progress after following your instructions to create the custom template.
When I ran service mysql.init restart
it hung on Loading cacti into mysql. After letting it sit for several minutes, I used Ctrl-C to get back to a prompt. At that point, I could see that the cacti_sme database wasn't yet created. I then restarted the server with the post-upgrade/reboot commands.
After the restart, I could see the cacti_sme database and associated tables now existed. However, when I tried to view Cacti through the web browser it was telling me that the Cacti database was not initialized - providing instructions to create a user and grant privileges - so it seems the commands in the custom template weren't executed? Or maybe I have to edit the Cacti config files to see what was set up in the custom template?
-
So, to get this working do I have to run the commands that Warren suggested for setting setting up the DB:
/usr/bin/mysql
use cacti_sme;
GRANT ALL PRIVILEGES ON cacti_sme.* TO cacti@localhost IDENTIFIED BY 'changeme';
use mysql;
GRANT SELECT ON `mysql`.`time_zone_name` TO 'cacti'@'localhost';
flush privileges;
I'm thinking these won't work as-is because we changed the password from the default "changeme" per a later post:
config setprop cacti DbPassword $(< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c${1:-32};echo;)
So if I need to update the commands that Warren suggested to use the new password, where do I find the password that was generated from mmccarn's command?
-
Show all of the cacti settings:
config show cacti
or just show the database password:
config getprop cacti DbPassword
-
Thank you for that.
I ran the commands Warren suggested but it kept coming back and saying 0 rows affected, so I suspected nothing was actually happening. I installed PHPMyAdmin so I could get a look at things a little better and I could see the cacti_sme DB was present, the cacti user was present but the permissions were not set. I manually set the permissions using PHPMyAdmin, but when I try to pull Cacti up in my browser it's still telling me it's not initialized:
The Cacti Database has not been initialized. Please initilize it before continuing.
To initilize the Cacti database, issue the following commands either as root or using a valid account.
mysqladmin -uroot -p create cacti
mysql -uroot -p -e "grant all on cacti.* to 'someuser'@'localhost' identified by 'somepassword'"
mysql -uroot -p -e "grant select on mysql.time_zone_name to 'someuser'@'localhost' identified by 'somepassword'"
mysql -uroot -p cacti < /pathcacti/cacti.sql
Where /pathcacti/ is the path to your Cacti install location.
The only bit that wasn't done manually (in Warren's commands) was the last part about /pathcacti/cacti.sql. I've noodled around in the /usr/share/cacti folder and don't see a cacti.sql file anywhere, so maybe this doesn't apply within SME.
The info in /usr/share/cacti/include/config.php seems accurate so I'm not sure where the hangup is now.
-
/usr/bin/mysql cacti_sme < /usr/share/doc/cacti-1.1.19/cacti.sql
-
If someone get the right sequence please note the issues on the bug and I will try and fix them.
-
That file has already been executed - I got an error about "table already exists". I checked in phpmyadmin and all the tables are there with data loaded per the cacti.sql file.
Something else is out of whack here and I'm not enough of a Linux person to take this very far. I might see if I can completely remove everything and then start from scratch and document as I go.