Archive for category Linux
Permissions ignored with Samba
After the issue regarding the ntpd process, I encountered another problem with my D-Link DNS-313. This time it was about permissions problem using Samba.
Because I have multiple user accounts sharing the same data, I added the following lines into the Samba configuration file (smb.conf):
create mask = 0774 directory mask = 0775 force create mode = 0774 force directory mode = 0775
With these properties, a user will have the permission to read any files created by another user and will also be able to edit them if both users are part of the same group.
However, it appeared that these properties had been ignored by Samba! 
Please note that the client was a Mac OS X 10.6.6 (Snow Leopard) and the Samba version on the NAS was 3.0.25a.
After some googling on the web, I found the following explanation on the contribs.org forum:
Samba 3.0.2x has the ‘unix extensions’ option set to ‘on’ by default. This allows Unix users who write to the Samba shares to set their own permissions bits. Mac OS X up until now has never attempted to do this, but from Leopard, any directory that gets created on a Samba share, get chmod’ed through this Samba extension.
Alright, this is clear enough! This means that we have to set the ‘unix extensions’ option to ‘no’ in our Samba configuration file:
unix extensions = no
The problem should be gone after restarting Samba. 
ntpd process on D-Link DNS-313
During the configuration of a D-Link DNS-313 which is basically a NAS (Network-Attached Storage), I got a serious but easy-to-fix problem.
In order to get access to the box by command line, I installed the Fonz fun_plug. I then wanted to automatically synchronise the internal time with some NTP Pool Time Servers. But, for some reason, the version of the ntpd process provided with fun_plug is completely freezing the NAS. I wasn’t able to find the root cause of it, trust me, I tried everything I could think of!
Please also note that the same process is working perfectly fine on his brother, the D-Link DNS-323. As I said, I can’t explain why… 
But there is a good news! The ntpd process is actually part of the D-Link DNS-313 firmware. And it is working fine! 
After double-checking, this process is however NOT part of the D-Link DNS-323 firmware. Why is that? Maybe D-Link got complaints from DNS-313 users and fixed it? Who knows…
Anyway, in order to get the ntpd process to work on the D-Link DNS-313, you need to replace the content of your ntpd startup script (/ffp/start/ntpd.sh) by the one below:
#!/ffp/bin/sh
# PROVIDE: ntpd
# REQUIRE: SERVERS
# BEFORE: LOGIN
. /ffp/etc/ffp.subr
name="ntpd"
command="/usr/sbin/ntpd"
ntpd_flags="-f /ffp/etc/ntpd.conf"
required_files="/ffp/etc/ntpd.conf"
start_cmd="ntpd_start"
ntpd_start()
{
# remove rtc and daylight cron jobs
crontab -l | grep -vw '/usr/sbin/daylight' | grep -vw '/usr/sbin/rtc' | crontab -
proc_start $command
}
run_rc_command "$1"
Relation between TortoiseSVN and locale
The other day, I got stuck on a problem with TortoiseSVN for about half a day! 
Yes, I know, it is a pretty long time to get a simple subversion client working…
The error I was continuously getting was:
Network connection closed unexpectedly
Nothing else! Nothing in the log files on both the client and the server.
The funny thing is that it was working perfectly fine using a command line client or even Eclipse Subversive.
After a (too) long time of investigation, I noticed that I was getting the following warnings when I was running the following command line directly on the server:
$ svn list svn+ssh://smoreau@localhost/data/svn/ svn: warning: cannot set LC_CTYPE locale svn: warning: environment variable LANG is en_US.UTF-8 svn: warning: please check that your locale name is correct smoreau@localhost's password: svnserve: warning: cannot set LC_CTYPE locale svnserve: warning: environment variable LANG is en_US.UTF-8 svnserve: warning: please check that your locale name is correct branches/ tags/ trunk/
Actually, any svn command was triggering the warning messages:
$ svn info svn: warning: cannot set LC_CTYPE locale svn: warning: environment variable LANG is en_US.UTF-8 svn: warning: please check that your locale name is correct
Could it possibly be related with my TortoiseSVN problem?
Because I didn’t have any other idea, I decided to give it a go. 
It appears that these warning messages came from a configuration problem around the locale package on the server. Indeed, look what we get if we run the locale command:
$ locale -a locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_COLLATE to default locale: No such file or directory C POSIX
After some more investigation, it looks like this problem appeared when I upgraded the version of the locale package via APT. 
Once again, I asked my friend Google to help me out. It suggested me the following solutions:
- Run
locale-gen en_US.UTF-8– Didn’t work - Run
update-locale LANG=en_US.UTF-8– Didn’t work - Run
dpkg-reconfigure locales– WORKED
In conclusion, I wasn’t able to use TortoiseSVN because of a configuration problem on the locale package after an upgrade… Does it make sense?
Using the ‘date’ command in your crontab
Crontab, as most people know, enables users to schedule commands or shell scripts to run periodically at certain times or dates.
The other day, this very useful Linux tool gave me a hard time!
Indeed, one of my commands wasn’t working in cron but was working perfectly fine when written in a shell console.
The faulty command looked like this:
0 5 * * 3 /data/script.sh > /data/script_`date +%y%m%d`.log 2>&1
If I run this command in a shell console, everything works fine and I get a log file containing today’s date in its filename. However, if I set this command line in my crontab, it doesn’t work and no log file is even created!
Reading the documentation of cron, I discovered the following statement:
Percent-signs (%) in the command, unless escaped with backslash (\), will be changed into newline characters, and all data after the first % will be sent to the command as standard input.
Well, this is good to know, isn’t it?
We need to escape the percent-signs on our command line.
So in order to get our ‘faulty’ command to run in cron, it needs to look like the following:
0 5 * * 3 /data/script.sh > /data/script_`date +\%y\%m\%d`.log 2>&1
Locale settings for your cron job
Do you get special characters problem when executing your bash script from a cron job?
And does the same script work fine when it is directly executed from the command line?
If yes, continue reading this article!
The reason of this characters problem is probably because of your locale settings.
Indeed, If you try to run the command locale from the command line and from a cron job, you may get different results such as:
| From the command line | From a cron job |
LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= |
LANG= LC_CTYPE="POSIX" LC_NUMERIC="POSIX" LC_TIME="POSIX" LC_COLLATE="POSIX" LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL= |
As you can see, the cron job is not using UTF-8. That must be the problem!
So the question now is how to change the locale settings for the cron job?
Some people say that you need to add the following environment variables to the crontab entry:
SHELL=/bin/bash LANG=en_US.UTF-8 LANGUAGE=en LC_CTYPE=en_US.UTF-8
But this actually didn’t work for me.
What you can do instead is create (if not already present) the file /etc/environment and add the following line:
LANG=en_US.UTF-8
The cron process will read this file when it starts, so you need to restart it in order to apply the change:
service cron restart
Hope this will fix your characters problem.