vicidial.org

hello vici-friends, long time no see :-)

Now, after a couple of days I have my vici-cluster up & running. One problem I had to solve was that the cluster is based on vicibox (3.0.6) whereas the old system actually is a vicidialNOW 1.3 system. I succeded in switching all phones (users,queues) to the new cluster while the old system was working parallelly. Now I wanted to move the web-server to the DB-server to get the old system clean to additionally install vicibox on that maschine.

How can I move the webserver with all that astguiclient-stuff to another server ? What I tried was (don't slap me) copy /var/www/html + /usr/share/astguiclient/ to the new server, chmod'ed the astgui-scripts and redirected web-access from the old to the new system. Well, the next morning, agents could log in and stay in the interface without any error, could make outbound calls and there was also no error. In the beginning everything seemed fine. Then some calls came in and the agents began working. I opened Real-Time-Monitor and it also looked fine. Then, after a few minutes, suddenly, the website (index.html) did not load completely. I was faced with the situation that 10 agents were taking inbound-calls but every new agent could not access the web-interface (before any login!) I tried to reach the admin interface, but the page just did not load completetly. When it then suddenly did open and the agent logged in, they were thrown out after 2 or 3 minutes, with the message, their session has been paused! Since I could not easily locate the error, I just switched back to the old web-server (vicidialNOW 1.3). In the end I just wonder why 10 people could login and then suddenly the system seemed overloaded (but it wasnt really).

I will go to check crontab and astguiclient-scripts. My big question is, if it is as easy to migrate a vici-web-server as it was to migrate mysql ? I mean, just setting up "any" httpd-webserver, having the webfiles and the correct astguiclient-scripts copied to there with correct crontabs ... that should do the trick, doesn't it ?

Of course I checked crontab on both systems, but maybe I made something wrong there (a script activated on old system what should better be run on web-db-combo). To keep it simple: If I got a clean Linux-Maschine, is it possible to migrate the webserver over there ? I don't wanna spam you with boring crontab-entries here, but (my favorites sentence here) "if someone could give me a hint, how to get that done, it would save me much time!"

thanks for your attention.

------
vicibox-cluster 3.0.6
astguiclient
VERSION: 2.2.1-237
BUILD: 100510-2015

P.S.: I also started with SuSE back in those days, but if you are used to modify text files, then yast can really get on your nerves !

maybe one problem could be different php versions ? e.g. php.ini ?

Furthermore I found the copied scripts and log-txt files (like vicidial_debug.txt) but as always I forget that "cp" normally resets the file rights and ownership ... maybe that explains, that (for a short period) people could log in and work, but when apache or another process wanted to write to those files, the permission was denied ... does this assumption makes sense ? I remember a similiar error where my vicidial_auth_entries.txt was not writeable and so agents could not log in ...

instead of copying files from one machine to the other, activate install.pl from the machine you are on. that way the files will all match the presently installed version properly.

if necessary, use svn to get all your files and even consider an upgrade to the latest while you are at it.

thanks, Bill.

Of course, I should have thought of it on my own -.-
I tried that and unfortunately the script couldn't find many relative paths. I do not have these messages at hand, but it always said "cannot stat ./bin", for example, but actually, in the working directory (where install.pl lies) there IS an DIR called ./bin.
This was the point when I copied the files manually, checked file-ownership and -rights. It did not make me happy. I will see tonight if it works :D Since I read something about "12 phone-server and 2 web-servers" I think I can get 2 webserver running in parallel (and then switch off the old one).

Have you ever heard of that "relative-path-problem" of install.pl ? I mean, if I execute it as root, why shouldn`t it be able for the script these directories (that belong to root) ?

perhaps you should look at the Vicidial Wiki and learn how to use SVN to get a clean proper install.

Or just use the backup script, fresh install, then restore ... you then have a stock, clean, installation.

I cannot guess why your install.pl file would have issues with location unless your astguiclient.conf file has values that lead it to missing directories.

hey,

well, it might be that I called the script from / but the script seems to need to be called from /usr/src/bla bla because it uses relative paths. I did not try it again, but that could explain it.

I almost got the new webserver running, but there are some things that irritated me. Since I had to move a vicidialNOW-webserver to a vicibox-webserver I thought most settings should be of the same. But they weren't. Maybe because the install-script did not work for me. I give you some settings that were differently configured on both servers and I'd like to know why ...

On VicidialNOW:
MaxClients 256
ServerLimit 256

On Vicibox:
MaxClients 150
ServerLimit 150

It took a while to find out why some agents could log in whereas others later on could not, because the page was not loaded ... now, after reading something about Apache's MPM modules, I understand more, but I don't get the sense, why these two settings are by default so low on viciboxes.

thank you for your attention.

hello again,

yet no answer ? okay, then here comes the next: I hope I don`t blame myself again, but I was suprised watching the apache error logs (which I set to notice) where it says:

Code: Select all

[Sun Feb 06 11:15:01 2011] [notice] Graceful restart requested, doing restart
...


to make it short: it also happened the day before and it was neither me nor a crontab; could find "at" or "anachron" on the system. Had a slight look into /etc/init.d/ but I have not a glimpse of an idea where to look for. Which process is restarting (reloading) the webserver at eleven 15 every day ?

hey,
to locate the process I was "top"-ing around 11.15; I found that:

Code: Select all

32613 root      35  15  9264 7640  388 R   99  0.0   5:00.71 bzip2


All I know is that mysql or apache logs might be "rolled" by logrotate and that it compresses the logs. But I cannot find any corresponding task or I don't know which script is reliable for this. In crontab I have only these .pl-scripts called ... is one of them compressing the logs and reloading the webserver ? As far as I know, one got to reload apache when it should change the log file ... that's how I came to this idea .... but still no idea where it comes from ... does it might be a script called from another (misconfigured) vicibox ?

self discussion sometimes help you out

It's all about "/etc/logrotate.d/apache2" ... it's a long time ago I played around with logrotate, and on a first sight, I cannot see how one can modify the execution time ... but I found the source of the reloads, so I give a feedback when I am smart enough to say anything about it: for example, how to force the system to do it at night, not in business times !

I hope SuSEconfig is not spitting in my soupper !

ok:
/etc/cron.daily calls logrotate; logrotate.conf includes /etc/logrotate.d
/etc/cron.daily is called by /etc/crontab which itself calls run-parts
run-parts calls /usr/lib/cron/run-crons which is like

Code: Select all

-*/15 * * * *   root  test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1


Solution: I set the variable "DAILY_TIME" in /etc/sysconfig/cron to a value that makes much more sense to me.
Notice: As far as I understood, run-parts refers to the server-start time; so it always tries to re-run the scripts at the same given time.
I think with the variable set in /etc/sysconfig/cron I have a working solution, but actually I'll see that tomorrow.

bye