Topic: Did updating DBI via Perl break SAIL?

[jufra]

Hi,

I'm running SME8 with SAIL 3.1.0-128
Last night I did something I shouldn't have done. I was playing around with perl and databases, and wanted to test a script that uses SQLite. So I issued the commands which I found on an SQLite tutorial page:
perl -MCPAN -e shell
cpan> install DBI
cpan> install DBD::SQLite

I don't know why I didn't check if DBI was already there (well, it was late and I just followed the tutorial without thinkig too much...  ). The installation took an awfully long time, but my perl script ended up working ok. This morning, I wanted to check something on my SME/Sail box (which is where I also tested the script), and to my surprise the GUI didn't give me the extensions, trunks, routes info anymore, but now says:
Software error:DBD::SQLite::st execute failed: database is locked at /opt/sark/perl/modules/sark/SarkSubs.pm line 1205.

I am assuming this is due to my playing around with DBI and SQLite. I regressed the database, stopped/restarted, rebooted, to no avail. I won't do anything further (like trying to get rid of SQLite again) as I don't want to break anything else. Asterisk is working ok, no problems there, just Sail has hiccups...
My question is did I break the SAIL installation? Or possibly even more since SME is heavily depending on Perl??
And also, is there any way to undo the changes I did?

Just in case this is relevant, I did a yum list installed | grep -i sql and it gave me the below printout. Note that this is 100% identical to another server with the same configuration that wasn't compromised in the way I described above:

Code: [Select]

yum list installed | grep -i sql
asterisk18-addons-mysql.i386         1.8.5.0-1_centos5                 installed
e-smith-mysql.noarch                 2.2.0-6.el5.sme                   installed
mysql.i386                           5.0.95-5.el5_9                    installed
mysql-server.i386                    5.0.95-5.el5_9                    installed
perl-DBD-MySQL.i386                  4.022-1.el5.rfx                   installed
perl-DBD-SQLite.i386                 1.14-1.el5.rf                     installed
php-mysql.i386                       5.3.3-13.el5.sme.1                installed
postgresql-libs.i386                 8.1.23-6.el5_8                    installed
python-sqlite.i386                   1.1.7-1.2.1.0                     installed
sqlite.i386                          3.3.6-6                           installed

Any comments most welcome - whilst I hang my head in shame and promise not to do anything like this ever again 
Thanks
Frank

[SARK devs]

Hi There
I think you may have installed an earlier or different version of DBI and DBD.

Without knowing what actually got installed by CPAN I'm not sure what to advise, short of a re-install from scratch.   Maybe you can get away with removing those perl CPAN modules and then remove/reinstall the sqlite DBD rpm perl-DBD-SQLite-1.14-1.el5.rf.i386.rpm

Best
S

[jufra]

Thanks S,

well, the list of installed rpms tells me that it is the version you are pointing out below, that's why I'm a bit confused.
My yum list installed told me:
perl-DBD-SQLite.i386                 1.14-1.el5.rf                     installed

That said, I'm not really that familiar with the CPAN install procedure, how exactly can I uninstall it?

So far the server is stable, but I'm not sure what will happen when I add/delete an Ibay or install any updates since it will then go and modify the database...

I'm in the process of backing everything up, preparing for the big reinstall if it cannot be avoided 

Thanks
Frank

[SARK devs]

Yes the rpm was installed (and yum will believe that it still is) but the likelihood is that CPAN overwrote one or more of its modules.   CPAN and yum/rpm don't mix well.  CPAN has no general delete/un-install mechanism that I'm aware of (doesn't mean that one doesn't exist) so you may need to figure out what it did and remove the modules manually. 

You can use rpm -e to remove the DBD rpm and then re-install it (which might fix your problem anyway and its an easy thing to do as a first step)

...or you can back up and rebuild.


Best
S

 

[jufra]

Thanks again S,

in the meantime I had a look around and also found CPAN does not have any uninstall procedure... bummer...
I ran a command to compare the difference in the /usr/lib/perl directories of my server and an indentical server which is "uncompromised". The differences are as follows (command I ran was  perl -MFile::Find=find -MFile::Spec::Functions -lwe 'find { wanted => sub { print canonpath $_ if /\.pm\z/ }, no_chdir => 1 }, @INC'). THe following files are not on the "uncompromised" server...

Code: [Select]

/usr/lib/perl5/5.8.8/CPAN/Config.pm
/usr/lib/perl5/5.8.8/CPAN/Meta/Converter.pm
/usr/lib/perl5/5.8.8/CPAN/Meta/Feature.pm
/usr/lib/perl5/5.8.8/CPAN/Meta/History.pm
/usr/lib/perl5/5.8.8/CPAN/Meta.pm
/usr/lib/perl5/5.8.8/CPAN/Meta/Prereqs.pm
/usr/lib/perl5/5.8.8/CPAN/Meta/Spec.pm
/usr/lib/perl5/5.8.8/CPAN/Meta/Validator.pm
/usr/lib/perl5/5.8.8/CPAN/Meta/YAML.pm
/usr/lib/perl5/5.8.8/ExtUtils/MM_Darwin.pm
/usr/lib/perl5/5.8.8/File/Copy/Recursive.pm
/usr/lib/perl5/5.8.8/JSON/PP/Boolean.pm
/usr/lib/perl5/5.8.8/JSON/PP/Compat5006.pm
/usr/lib/perl5/5.8.8/JSON/PP.pm
/usr/lib/perl5/5.8.8/Parse/CPAN/Meta.pm
/usr/lib/perl5/5.8.8/Test/Builder/IO/Scalar.pm
/usr/lib/perl5/5.8.8/version.pm
/usr/lib/perl5/5.8.8/Version/Requirements.pm
/usr/lib/perl5/5.8.8/version/vpp.pm
/usr/lib/perl5/site_perl/5.8.8/Email/Date/Format.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/Bundle/DBI.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/DBM.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/ExampleP.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/File.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/Gofer.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/Gofer/Policy/Base.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/Gofer/Policy/classic.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/Gofer/Policy/pedantic.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/Gofer/Policy/rush.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/Gofer/Transport/Base.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/Gofer/Transport/corostream.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/Gofer/Transport/null.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/Gofer/Transport/pipeone.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/Gofer/Transport/stream.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/NullP.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/Proxy.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/Sponge.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/SQLite.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/Changes.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/Const/GetInfo/ANSI.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/Const/GetInfo/ODBC.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/Const/GetInfoReturn.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/Const/GetInfoType.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/DBD/Metadata.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/DBD.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/DBD/SqlEngine.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/FAQ.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/Gofer/Execute.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/Gofer/Request.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/Gofer/Response.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/Gofer/Serializer/Base.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/Gofer/Serializer/DataDumper.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/Gofer/Serializer/Storable.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/Gofer/Transport/Base.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/Gofer/Transport/pipeone.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/Gofer/Transport/stream.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/ProfileData.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/ProfileDumper/Apache.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/ProfileDumper.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/Profile.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/ProfileSubs.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/ProxyServer.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/PurePerl.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/SQL/Nano.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/Util/_accessor.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/Util/CacheMemory.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI/W32ODBC.pm
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/Win32/DBIODBC.pm
/usr/lib/perl5/site_perl/5.8.8/MIME/Lite.pm
/usr/lib/perl5/site_perl/5.8.8/MIME/Type.pm
/usr/lib/perl5/site_perl/5.8.8/MIME/Types.pm

I guess it does not really suffice to delete those files relating to DBD and DBI, there must be more to it?
I might just complete my full backup and then run the command you suggested, ie, uninstall and reinstall the DBD rpm, maybe that fixes it. It sounds logical to me...maybe I stop Sark first.
Do you think I need to attempt any manual removal of the CPAN modules or just go ahead with the yum uninstall and reinstall and see what happens?

Thanks again, if this works, it will make my day, believe me... anyhow, getting late here in down under, will do it tomorrow,
Cheers
Frank

[jufra]

Ok, tried everything I could, still no go.
I did a forced reinstall (rpm -Uvh --force) of the following rpms:
perl-DBD-SQLite-1.14-1.el5.rf.i386.rpm
perl-DBI-1.622-1.el5.rfx.i386.rpm
sqlite-3.3.6-6.i386.rpm

and did a reboot with reconfiguration after that. Database is still locked. Then went down the road of trying to unlock the database file using 2 methods
1. did an sqlite3 .backup command (which I read leaves the backed up database unlocked). No go
2. dumped the DB into a new file (sqlite3 sark.db .dump > sark_new.db) and then copied the file back. No go. Put the new file into the backup dir and regressed via the GUI, also no go...

Any suggestions STILL VERY welcome!!
Pretty much at my wits end here. So I think I will have to go down the reinstall path... ?

Thanks for all the good advice, much appreciated
Cheers
Frank

[jufra]

Ok, another long night, finally this morning got it back up working. What I did was to remove sail.noarch and also smesailenv.noarch and reinstalled it along with the perl-sqlite module. Tried sail version 4.0.0-58 first, that was a no go, but version 3.1.1-27 installed ok, gui is up again and calls are normal...

So I was spared the complete reinstall of SME, phew....

Thanks again
Cheers
Frank