Vesta CP and RoundCube Mail database error - php

Hello all i am having a vps server with vesta installes but i am having database connection error with roundcube here ..
I read this article https://forum.vestacp.com/viewtopic.php?t=4375
and helped me to understand the issue
And the solution is
This issue appeared for me because roundcubemail wasn't fully installed and configured during the Vesta install process. To get it working I needed to set the following line to true instead of false in /etc/roundcubemail/main.inc.php:
CODE: SELECT ALL
$rcmail_config['enable_installer'] = false;
Then run the roundcubemail installer by going to http://domain.org/webmail/installer/
And to complete the installer successfully after I got to the point that it complained that I had no readable config.inc.php I needed to copy the config.inc.php the installer generated into /etc/roundcubemail/ and set that file to the same readability as the other config files in that directory and then set the same option:
CODE: SELECT ALL
$rcmail_config['enable_installer'] = false;
once again to true, but in the new file config.inc.php rather than /etc/roundcubemail/main.inc.php.
The installation then completed correctly and at that point I set the enable_installer lines I referenced above back to false in both
/etc/roundcubemail/main.inc.php
and in /etc/roundcubemail/config.inc.php so that they would no longer be in installer mode. Not sure if this is a Vesta bug – my understanding was that dependencies like Roundcubemail would be completely installed and configured in the Vesta install process but maybe that's incorrect.
but i dont know how to access the etc folder from my server by ssh
As when i login i only see thse when ls
f.txt login.info vst-install-rhel.sh vst-install.sh vst_install_backups
and when entered into vst_install_backups i get these
clamd dovecot exim httpd mongodb mysql named nginx php php-fpm postgresql proftpd spamassassin vesta vsftpd
Please help me solve the roundcube and vesta issue ..

I have just same problem. I have solved it by next steps:
1) Login in phpmyadmin under root (password for root should be same as for vesta).
2) Create database roundcube
3) Create user roundcube with privilegies
CREATE USER 'roundcube'#'localhost';
SET PASSWORD FOR roundcube#localhost = PASSWORD('<password>');
GRANT ALL PRIVILEGES ON roundcube.* TO roundcube#localhost;
you can find password there: /etc/roundcube/db.inc.php
4) Login by ssh to the server and run script:
mysql roundcube < /usr/share/dbconfig-common/data/roundcube/install/mysql
This is sql from installation of vesta

Related

"-1" file created in app root directory when running php artisan

I am running Laravel on Homestead, and whenever I run any php artisan XXX command, the file named -1 is created in the root directory of the app.
Contents of the file are similar to these ones:
Log opened at 2017-12-22 13:54:00
I: Connecting to configured address/port: 10.0.2.2:9000.
E: Time-out connecting to client. :-(
Log closed at 2017-12-22 13:54:00
I am 99% sure it is related some changes I made in my failed attempts to make XDebug breakpoints work with artisan commands. I have exported some shell variables, as recommended in this answer, but when I run export -p I don't see any of them.
Did anyone have a similar issue? What setting can be causing such behavior?
Following the suggestion of LazyOne, I found the answer:
It seems that paths in .ini file have to be absolute. So instead of:
xdebug.remote_log=~/code/xdebug.log
I had to set it to:
xdebug.remote_log=/home/vagrant/code/xdebug.log
and now it works as supposed to.

vtiger Call to a member function Execute() on null in C:\xampp\htdocs\vtigercrm\include\database\PearDatabase

I am installing vtiger,
when i open the index page,
i got this error:
Fatal error: Call to a member function Execute() on null in C:\xampp\htdocs\vtigercrm\include\database\PearDatabase.php on line 357
i opened the PearDatabase.php file, and I found this:
if($this->avoidPreparedSql || empty($params)) {
$sql = $this->convert2Sql($sql, $params);
$result = $this->database->Execute($sql);
} else {
$result = $this->database->Execute($sql, $params);
}
the line 357 is:
$result = $this->database->Execute($sql);
If you have installed vtiger once locally, you have to clean cookies in your brower of your local vtiger domain.
That should fix your problem, what a amazing bug it is!
Make sure you have installed all the pre-requisites:
Pre-requisites from here:
Apache 2.1+
MySQL 5.1+ (default storage engine = InnoDB)
PHP 5.2+, 5.3
php-imap
php-curl
php-xml
max_memory (min. 256MB)
max_execution_time (min. 60 seconds)
error_reporting (E_ALL & ~E_NOTICE & ~E_DEPRECATED)
Hardware: 4 GB RAM, 250 GB Disk (for file attachments)
The error is suggesting that it can't work out what to do with the back end database.
You will receive this error when installing vTiger if your session_save_path() is not writable by your web server user.
In my case, my 'session_save_path' was /var/lib/php/7.1/session and was owned by root. I am using Nginx so I executed the following command to resolve my issue:
sudo chown -R nginx:nginx /var/lib/php/7.1/session
If you are using Apache, you would execute the following command to resolve your issue:
sudo chown -R www-data:www-data /var/lib/php/7.1/session
The information entered into the vTiger wizard is saved to $_SESSION as you navigate through the installation steps.
When the 'session_save_path' is owned by root rather than the web server user, the session data is not saved between function Step5() and function Step6() in modules/Install/views/Index.php. So when the config.inc.php file is created by the wizard, all the configuration data you entered into the form is not written to config.inc.php since your data was not saved in $_SESSION between the requests. This can be fixed by changing the permissions on your 'session_save_path' to be writable by the web server user.
You can find your session.save_path in your php.ini file or your www.conf file if you are using php-fpm:
/etc/php-fpm-7.1.d/www.conf:php_value[session.save_path] = /var/lib/php/7.1/session
This unhelpful error is actually because your database connection is unsuccessful in file include/database/PearDatabase.php in function connect() since all the database variables are empty.
Hope this helps.

Drush command(s) run on Drupal 6 sites, but not Drupal 7?

I am running into an issue with a customer's Drupal sites. He has a number of D6 installs, and a new D7 that he's just starting on. All of these sites are on the same shared hosting package.
The problem is when running certain drush commands only on the D7 site. There are no issues on the D6 sites. The specific error for drush up on the D7 site follows:
foo#bar [~/www/foo]# drush up
Command pm-update needs a higher bootstrap level to run - you will need to invoke drush [error]
from a more functional Drupal environment to run this command.
Command pm-update needs the following modules installed/enabled to run: update. [error]
The drush command 'up' could not be executed. [error]
Drush was not able to start (bootstrap) the Drupal database. [error]
Hint: This may occur when Drush is trying to:
* bootstrap a site that has not been installed or does not have a configured database. In
this case you can select another site with a working database setup by specifying the URI
to use with the --uri parameter on the command line. See `drush topic docs-aliases` for
details.
* connect the database through a socket. The socket file may be wrong or the php-cli may
have no access to it in a jailed shell. See http://drupal.org/node/1428638 for details.
Drush was attempting to connect to:
Drupal version : 7.28
Site URI : http://default
Database driver : mysql
Database username : username_foo
Database name : database_foo
PHP configuration :
PHP OS : Linux
Drush version : 7.0-dev
Drush temp directory : /tmp
Drush configuration :
Drush alias files :
Drupal root : /home/foo/www/foo
Site path : sites/default
Everything I can find (and indeed the link in the error message) say the solution is to change the host value in the settings.php file from localhost to 127.0.0.1. However, this has not been the solution for us.
The frontend site has no problems connecting to the database, and drush itself seemingly does in many cases too.
drush sql-connect will generate a string that you can use to connect to MySQL.
drush sql-cli will successfully connect to MySQL
The settings.php file is definitely in a folder called default (path: www/foo/sites/default) and I get the exact same error when specifying --root and --uri options.
Drush was originally a ~5.x release, and it had the same issues. We updated to the ~7.x to try to eliminate the error. The host value in settings.php has been localhost as well as 127.0.0.1 with equally poor results.
We've verified that MySQL is available via socket from the PHP CLI. Drush is up to date and a fresh install. The Drupal 7 site is a brand new fresh install.
I'm at a loss. Why would this work with the D6 sites, but not the D7? Any suggestions?
Is your settings.php file in a folder called 'default'? If not, you might need to tell Drush where to find it by using --uri=mysite.com or -l mysite.com.
There are several ways to specify which Drupal site Drush will target. The most basic option is fairly verbose; run:
$ drush --root=/path/to/drupal --uri=http://example.com status
You can do the same thing with a slightly different syntax:
$ drush /path/to/drupal#example.com status
You can also specify the Drupal site implicitly, by setting the cwd to the folder that contains the settings.php file for your site:
cd /path/to/drupal/sites/default # or /path/to/drupal/sites/mysite.com, as appropriate
$ drush status
In all of the cases above, if settings.php is in a folder called "default", then you do not need to specify the --uri component; you may, for example, cd /path/to/drupal followed by drush status, and the correct Drupal site will be found. If settings.php is not in a folder named 'default', then you will need to either specify --uri, or cd to the folder that contains the settings.php file.
Source
According to this message:
pm-update needs the following modules installed/enabled to run: update
Drush requires Update module to be enabled, so the following command should fix the problem:
drush -y en update

MySQL Database won't start in XAMPP Manager-osx

I downloaded XAMPP about a month ago and it was working just fine. Today I installed a voice recognition software and then restarted my computer. Ever since, MySQL won't start in my manager-osx application. It doesn't throw me an in the application log. This is what it says:
Stopping all servers...
Stopping Apache Web Server...
/Applications/XAMPP/xamppfiles/apache2/scripts/ctl.sh : httpd stopped
Stopping ProFTPD...
Checking syntax of configuration file
/Applications/XAMPP/xamppfiles/proftpd/scripts/ctl.sh : proftpd stopped
Restarting all servers...
Starting MySQL Database...
Starting Apache Web Server...
/Applications/XAMPP/xamppfiles/apache2/scripts/ctl.sh : httpd started
Starting ProFTPD...
Checking syntax of configuration file
/Applications/XAMPP/xamppfiles/proftpd/scripts/ctl.sh : proftpd started
Both my ProFTPD and my Apache Web Server are running. MySQL isn't.
When I go to phpmyadmin, it throws me this error message.
#2002 - No such file or directory
The server is not responding (or the local server's socket is not correctly configured).
Please help me. I have no idea what to do.
UPDATE:
After looking around the internet a bit, I found a similar problem a user had with MAMP, another user recommended killing the mysql process, what ever that means. Could this be a fix to my problem?
UPDATE 2:
I found the answer to my problem but I can't answer it yet. So here's the answer:
1) Open terminal and type
sudo su
and then put in your password
2) Then type
ps aux | grep mysql
(just copy and paste this)
3) You will need to get the process id of mysql. There should be number near the top, something like 739 or 8827
4) Kill the process using
kill -9 {process id}
this should look something like this: kill -9 739
5) Restart MySQL in manager-osx
This should work:
sudo /Applications/XAMPP/xamppfiles/bin/mysql.server start
Minimal Guide
1.
sudo killall mysqld
2.
manager-osx > start mysql
If that didn't work...
sudo /Applications/XAMPP/xamppfiles/bin/mysql.server start
Google the error...
Examples:
Error:
ERROR! The server quit without updating PID file (/Applications/XAMPP/xamppfiles/var/mysql/<computername>.local.pid)
My Solution:
In /Applications/XAMPP/xamppfiles/etc/my.cnf change user = <uid> s that <uid> is uid from id command.
$ id
uid=...
$ vim /Applications/XAMPP/xamppfiles/etc/my.cnf
...
If these commands don't work for you:
sudo killall mysqld
sudo /Applications/XAMPP/xamppfiles/bin/mysql.server start
Try this:
For XAMPP 7.1.1-0, I changed the port number from 3306 to 3307.
Click on Manage Servers
Select MySQL Database
Click on Configure on your right
Change your port number to 3307
Click OK
Close your Control Panel and relaunch it.
You are now good to go.
check the err log on your /Applications/XAMPP/xamppfiles/var/mysql/ with filename like your_machine_name.local.err, if you find something like: "Attempted to open a previously opened tablespace. Previous tablespace ... uses space ID"
the following works for me:
edit file:
/Applications/XAMPP/xamppfiles/etc/my.cnf
find the [mysqld] section, add one line:
innodb_force_recovery = 1
then run
sudo /Applications/XAMPP/bin/mysql.server start
everything is ok again.
and then the last step:
edit the my.cnf again and remove the line you just added :
innodb_force_recovery = 1
and restart mysql again. Otherwise all your tables will be read only
Try running these two commands in the terminal:
sudo killall mysqld
sudo /Applications/XAMPP/xamppfiles/bin/mysql.server start
For me the following worked: Change permission into 'read only' for 'everyone' to the file /Applications/XAMPP/xamppfiles/etc/my.cnf. Then start MySQL from XAMPP manager.
close XAMPP control
sudo killall mysqld
sudo /Applications/XAMPP/xamppfiles/bin/mysql.server start
it happened to me. and
sudo /Applications/XAMPP/xamppfiles/bin/mysql.server start
not work for me.
so, i reinstall the xampp, then fix it.
attention:
reinstall the xampp, will not delete mysql data, no need to worry about that.
I first couldn't manage to kill mysql daemon with the commands posted here. So I remembered my linux times and did the following:
I monitored the running processes by running top in one terminal window. Then I killed mysqld via sudo killall mysqld (screw the PID ;-) ) in another and restarted via sudo /Applications/XAMPP/xamppfiles/bin/mysql.server start.
There's been a lot of answer, but I think I found what is causing it, at least for me. It looks like if you put your computer to sleep (or it falls asleep on its own), when it reopens, it tries to open the the mysql process again. At one point I looked at my activity monitor and I had 5 instances running - killing all of them and then starting mysql works.
sudo /Applications/XAMPP/xamppfiles/bin/mysql.server start
This worked for me.
I had success with easy killing all active mysql processes in Monitor Activity tool:
1) close XAMPP control
2) open Monitor Activity
3) select filter for All processes (default is My processes)
4) search for: mysql
5) force quit all the mysql
6) relaunch XAMPP control and launch apache again
Enjoy
try these two line from terminal
sudo killall mysqld
sudo /Applications/XAMPP/xamppfiles/bin/mysql.server start
on
macOs High Sierra
if mysql is not getting started from manager- oxs and have tried direct command i.e
sudo /Applications/XAMPP/bin/mysql.server start
too than
go to path edit
/Applications/XAMPP/xamppfiles/etc/
find file :
my.cnf
edit it
under the [mysqld] section, add following line:
innodb_force_recovery = 1
after it save and run or can be done from manager-osx
sudo /Applications/XAMPP/bin/mysql.server start
it should start the mysql.
once its run you need to again
edit the
my.cnf
file and remove the line just added
innodb_force_recovery = 1
stop and start mysql again. by command
sudo /Applications/XAMPP/bin/mysql.server start
or
by manager-osx
it will be working fine.
It can cause because of the software you installed or may be any other software which is using the same port 3306. This 3306 port is used by the Mysql in XAMPP. Similar kind of problem I faced for Apache. I was running skype and trying to run the XAMPP but the skype uses the same port as Apache so it was not working. Then I sign out from skype then the port was free and the apache started. So you should look for the software in you laptop which is blocking or making busy this port. Free that port by closing the software and then run XAMPP and It will work.
What I did was the following: In XAMPP Control Panel I edited the my.ini file of configuration of MySql and changed the port from 3306 to 3307 and it worked, hope it helped!
Edit: after you save this changes be sure that the service is off and then restart the service. I had this same problem when I installed MySQL, it's just the port.
I encountered this problem just now. I checked log file and found it is caused by the server was not shutdown correctly. So I found this http://rivenlinux.info/how-to-recover-innodb-corruption-for-mysql/ and add a simple configuration "innodb_force_recovery = 1" in [mysqld] in my.cnf. Then the problem was solved.
The log file is located /Applications/XAMPP/xamppfiles/var/mysql and it named accroding to your server name. Just link this XXX-MacBook-Pro.local.err
All the answers stated above in relation to changing the port number are in this situation the best way to solve this problem since you need your voice recognition software to coexist with MAMP. However, you must remember that changing this port number is going to affect all you subsequent connections to MySQL (i.e, terminal,php code,phpmyadmin,etc). Hence It would be advisable to change the port on which the voice recognition software runs. Hope this was helpful.
:)
if you are getting this error
.............ERROR! The server quit without updating PID file
Try this
Go to /Applications/XAMPP/xamppfiles/var/mysql/
if there is no file with the name Your_Username.local.pid
Your_Username should replace with your Mac Username
Create a file with this name
Then try
sudo /Applications/XAMPP/xamppfiles/bin/mysql.server start
its worked for me
It had the same problem, all I did was give read-only permissions for ALL users (system included) and all items included in the following folders:
/Applications/XAMPP/xamppfiles/etc
/Applications/XAMPP/xamppfiles/sbin
and relaunch XAMPP control and launch mysql server again
or
sudo /Applications/XAMPP/xamppfiles/bin/mysql.server start
I have same problem and get this error in hostname.err in directory /Applications/XAMPP/xamppfiles/var/mysql
2016-09-06 15:32:45 140735322399488 [Note] Plugin 'FEEDBACK' is
disabled. 2016-09-06 15:32:45 140735322399488 [Note] Heuristic crash
recovery mode 2016-09-06 15:32:45 140735322399488 [Note] Please
restart mysqld without --tc-heuristic-recover 2016-09-06 15:32:45
140735322399488 [ERROR] Can't init tc log 2016-09-06 15:32:45
140735322399488 [ERROR] Aborting
2016-09-06 15:32:48 20004 mysqld_safe mysqld from pid file
/Applications/XAMPP/xamppfiles/var/mysql/hostname.pid ended
Then I removed tc.log and It works fine after restart mysql through manager-osx
This could be due to the fact that another instance of mysqd is already running in your mac-book-pro (MacOs-10). It's next to impossible to kill/pkill mysqld or ....I tried that route many times, with out any success. Finally the following worked for me :
launchctl unload -w /Library/LaunchDaemons/com.oracle.oss.mysql.mysqld.plist
wait a few minutes and check with
ps -ef|grep mysqld
It should be gone!
It might be the possibility that your voice recognition software has a installer of mysql internally and when u installed this software, it has installed mysql too and added it to the service and this mysql service starts once your system starts. So now u r having two mysql servers (one from voice recognition software and second is from XAMPP) that's why killing the previous process (mysql service) solved your problem. But this is not a permanent solution, you have to repeat it every time when ever you start your machine. So better is to find out that mysql server (service) and change its port no. OR change settings so that mysql service should not start when your machine start (but might be your voice recognition software won't work properly)
I hope it will help you.
Cheers
You seem to have found a work-around by killing the process, but make sure you check for free space on your MySQL partition. If your logs or db files are consuming all your drive space, mysqld will not start.
Restarting the computer, or using the 'kill' commands listed above solve the problem. AS for preventing it from happening, I've found this occurring anytime my computer goes to sleep. The port is obviously kept reserved, and then on wake, mysql tries to reconnect to that port, but can't. This could be your problem also.
I am running XAMPP 5.6.3-0 for OS X Yosemite 10.10.2 and ran into the same issue twice, the first time was with Mavericks. With a bunch of different solutions to the issue with MySQL Database not starting using Manager App I wanted to confirm what had worked for me. The workaround that always worked and forced MySQL to start was by opening Terminal and using:
sudo /Applications/XAMPP/xamppfiles/bin/mysql.server start
I had the Manager App open and started ProFTPD and Apache and then ran the sudo command.
The other suggestion by wishap that worked was to locate /Applications/XAMPP/xamppfiles/etc/my.cnf file and change the permissions for "everyone" to Read only.
The other problem I had that seems to be another issue with many solutions is the problem after everything is started then entering localhost which brings me to the xampp splash screen and then nothing. The only thing that worked for me, to at the very least, to access the phpMyAdmin page is by entering localhost/phpmyadmin
I hope this helps others reading through a bunch of threads for an answer.
Regards,
Erik
Try this, sudo service mysql stop it will stop any other mysql services and then restart xampp
Just Click on Managed Servers Tab in XAMPP MANAGER , Now select MySQL Database, Click on configure on right side.
Change port from 3306 to 3307 and it will work.
It had the same problem, all I did was give read-only permissions for all users and all items included in the following folders:
/Applications/XAMPP/xamppfiles/etc
/Applications/XAMPP/xamppfiles/sbin
Well, sometime there is just ERROR! message is shown in mysql comment on terminal.
Then, just reinstall (overwrite) XAMPP, then it can be solved.

phabricator on redhat's openshift

I installed phabricator on openshift using a quickstart from github
https://github.com/CodeBlock/phabricator-openshift-quickstart
I got it running up fine, but I now have two issues:
1.) A setup issue that says apc.stat is enabled and that must be disabled in
/var/lib/openshift/my-user-hash/php/configuration/etc/php.ini
however I cannot access that with sudo command(sudo permission denied), even if I open it normally, I didn't find any apc.stat settings in the php.ini
2.) I can't figure out how set the local path for tracking repositories for diffusion. It says
I must give a path which should be read-writable by phabricator, I tried to give the persistent storage location ..data/ , but it gives me an exception as follows :
Unhandled Exception ("CommandException")
Command failed with error #1!
COMMAND
(cd '../data/' && HOME='/var/lib/openshift/my-user-hash/app-root/runtime/repo/phabricator/support/empty/' git cat-file --batch)
STDOUT
(empty)
STDERR
sh: line 0: cd: ../data/: No such file or directory
how do I fix this?
1) According to Num Duong answer, it seems like u currently could not resolve this issue, probably u should wait for openshift php.ini permissions policy changes.
Anyway this is minor non blocking issue.
2) Modify config file and re-deploy to openshift.
Look for available phabricator options here
U need smth like this: 'repository.default-local-path' => getenv('OPENSHIFT_DATA_DIR'),
P.S. Anyway there is one particular issue with phabricator on openshift that possibly never got resolved: cloning git repositories from OpenShift instances into Phabricator do not
work by SSH, due to permissions regarding the ssh configuration.

Categories