LinuxHostingSupport

While updating the ClamAV database using the ‘freshclam’ command, you may receive the “can’t open or parse the config file freshclam.conf” message.

root@vps:~# freshclam
ERROR: Please edit example config file /usr/local/etc/freshclam.conf
ERROR: Can't open/parse the config file /usr/local/etc/freshclam.conf

The reason is, with the default installation, the ‘Example’ variable is set to On which makes the configuration file work as a example and not the real configuration file.

To fix the issue, edit the freshclam.conf file

# nano /usr/local/etc/freshclam.conf

and remove or comment the line that says ‘Example’.

#Example

Save the file and execute the freshclam command to update the ClamAV database.

Sometimes people host applications that are fully Java based and don’t require a Webserver to access their application. However, in such a case, the application has to be accessed with port 8080 i.e. http://domainname:8080 which is not feasible.

There are 2 ways for the Java application to work on port 80, so people don’t have to mention port 8080 in their URL We will take a look at each of the above 2 options below:

1. The easiest way is to change the Tomcat port from port 8080 to 80 in the conf/server.xml file. This file is inside the Tomcat folder. 

To locate the file, update the mlocate database first (this command will take sometime to complete):

# updatedb

now, search the server.xml file using the locate command:

# locate server.xml

Open the file in the edit mode

# nano server.xml

and search for the below section

<Connector port="8080" Protocol="HTTP"
maxHttpHeaderSize="8192"
connectionTimeout="20000"
/>

Replace port 8080 with 80 and restart the Tomcat service.

2. The second method is to use iptables rules to redirect traffic received on port 80 to port 8080.

To add the iptables redirect rules, SSH to your server as root and execute the below commands:

# iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT
# iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT
# iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j \
REDIRECT --to-port 8080

To make the rules permanent

# service iptables save

Applying any of the above 2 methods will make the Java application work without the use of port 8080 in the URL.

Screen is used to run interactive programs in the backgroud while we can logout from the server. We can also re-attach to the existing screen session to check the progress of the running programs.

Sometimes, server admin need to run commands under a different user so they “su” to another user and use screen.

root@server [~]# su - user1
user1@server [~]# screen
Cannot open your terminal '/dev/pts/0' - please check.

As you can see, after changing the identity to ‘user1’, you cannot run screen and instead it exits with the error message

Cannot open your terminal '/dev/pts/0' - please check.

This indicates that the ‘user1’ don’t have access to the /dev/pts/0 file.

This is because the terminal is owned by the user (root) who opens the session so even if you su to another user (user1), the terminal will still be owned by the original user (root) hence the error.

Here are the permission and ownership of the terminal:

# ls -la /dev/pts/0
crw--w----  1 root tty 136, 0 Oct 28 04:34 /dev/pts/0

As you can see the ‘user1’ have no permission to read and write to the file. The file is only readable by root and writable by root and tty group.

There are 4 different solutions as stated below out of which 1st and 2nd are not recommended. They are a security risk and only recommended if you want to perform a very small tasks.

With the first 2 solutions, you may end up giving unprivileged access to a privileged login if you don’t revert the changes.

1) Set read/write permissions for ‘all’ on the terminal device in question which is /dev/pts/0 in our case. This way you can su to any user and run a screen session under his session.

# chmod a+rw /dev/pts/0

2) Set read permission to ‘tty’ group and then add the user ( in our case ‘user1’ ) to the ‘tty’ group in /etc/group file.

# chmod g+r /dev/pts/0

Open /etc/group file and search for tty:x:5: , at the end of the line add the username so he will be a part of the ‘tty’ group

tty:x:5:user1

Make sure you remove the user from the tty group once you complete your task.

3) This is the safest solution and is recommended. Set a strong password for user1, SSH directly with the user and run the screen session under it.

4) This is an alternate solution for the 3rd method.

a) Start a screen session as root
b) change to user1 with su command
c) execute your scripts/command
d) detach (don't terminate) from the screen using Ctrl a+d

I have a server with ‘root’ access but when I tried to SFTP in with the SSH Explorer client, it came up with a “subsystem request for sftp failed” error message. When trying to SFTP in, the SSH (/var/log/secure) logs came up with the following error:

sshd: subsystem request for sftp
sshd: error: subsystem: cannot stat /usr/libexec/sftp-server: No 
such file or directory
sshd: subsystem request for sftp failed, subsystem not found

A user can SFTP in only when SSH access is enabled for the user, in my case, I was using ‘root’ as user and was able to SSH in fine.

On further investigation, I found the ‘Subsystem’ parameter for sftp is defined in the SSH configuration file /etc/ssh/sshd_config.

# grep Subsystem /etc/ssh/sshd_config
Subsystem  sftp  /usr/libexec/sftp-server

This indicates that SFTP is looking /usr/libexec/sftp-server file which is missing

# ls -la /usr/libexec/sftp-server
/bin/ls: /usr/libexec/sftp-server: No such file or directory

The solution is to find the actual location of the ‘sftp-server file and

1) Creating a symlink to it in the /usr/libexec/ directory
OR
2) Edit the SSH configuration file and specify the correct path to the ‘sftp-server’ file in the ‘Subsystem’ parameter.

Locate the sftp-server file:

# find / -name sftp-server
/usr/libexec/openssh/sftp-server

and create a symlink to the actual file

# ln -s /usr/libexec/openssh/sftp-server /usr/libexec/sftp-server

Restart the SSHD service

# service sshd restart

You should be able to SFTP in successfully.

Recently I was configuring PHP with Mysql manually and it was really annoying to see the “Cannot find libmysqlclient under /usr” error message. The configure line I used to install PHP was

./configure --with-mysql  --with-libdir=/usr/lib

and the error that I received was

checking for MySQL UNIX socket location... /var/lib/mysql/mysql.sock
configure: error: Cannot find libmysqlclient under /usr.
Note that the MySQL client library is not bundled anymore!

The error occurred because libmysqlclient wasn’t present in the /usr/lib directory. On further investigation, I noticed the libmysqlclient is installed in the /usr/lib64 directory because the server is a 64bit machine.

So the fix for the “mysql: Cannot find libmysqlclient under /usr” error message is to provide lib64 directory path in the configure line.

The configure line should read as follows:

./configure --with-mysql --with-libdir=lib64

That’s it.