Friday, December 2, 2016

Redmine - 500 error when upload files

For couple years, users could not upload files into our Redmine instance when creating or updating issues (or tickets). We ignored it because most of the tickets were created from the email pulling task (IMAP) and the attachments were created just fine. But when we developed an external tool to manipulate issues with attachment, I think it's time to seriously looking at the problem and fix it.

Here is the command we try (upload file using Redmine's Rest API):

# curl '' -X POST -H 'X-Redmine-API-Key: <myapikey>' -H 'Content-Type: application/octet-stream' --data-binary "@myfile.png"

and errors (/var/log/redmine/default/production.log):

Completed 500 Internal Server Error in 15.4ms
Errno::EACCES (Permission denied - /var/lib/redmine/default/files/2016/12):
  app/models/attachment.rb:108:in `files_to_final_location'
  app/controllers/attachments_controller.rb:88:in `upload'

Reading the error logs you will see there is a permission problem in the file storage. So I went to the folder and check its ownership:

# cd /var/lib/redmine/default/files/

There is some directories that were owned by root. I changed the owner to www-data and everything worked like a charm:

# chown -R www-data:www-data /var/lib/redmine/default/files/

Monday, November 28, 2016

Migrate from manual-installed gitlab 7.8.1 to omnibus gitlab-ce 8.14.0

As you may already know, you can only restore your backups in the same gitlab version. So it means that you cannot move your old repositories to the newer version of gitlab using the backup/restore method. Fortunately there is another way to import those repositories into gitlab. Follow these instructions:

In my case, I want to migrate my old repositories from a manual-installed gitlab v7.8.1 to omnibus gitlab-ce 8.14.0 instance which were installed on the same server.

1. Create a group folder in the gitlab-ce's repositories directory:

sudo -u git mkdir /var/opt/gitlab/git-data/repositories/geniuses

2. Copy the old repositories (repositories in gitlab are bare ones):

sudo cp -r /home/git/repositories/* /var/opt/gitlab/git-data/repositories/geniuses/

3. Correct the permissions of the new folder and all of its sub-directories:

sudo chown -R git:git /var/opt/gitlab/git-data/repositories/geniuses/

4. Import the new copied repositories:

sudo gitlab-rake gitlab:import:repos

All the imported repositories will be own by the super admin of the omnibus gitlab-ce instance.

5. Add all existing user to the new imported repos:

sudo gitlab-rake gitlab:import:all_users_to_all_projects


Wednesday, November 23, 2016

No network after upgrade to 16.04 and how to fix

After upgraded to Ubuntu 16.04 from 14.04, my server network stop functioning (cannot ping gateway or anything...). I tried several things but none of them works (especially this one). So I ran these command to check my server's network status:

$ sudo ifconfig

=> There's only the loopback interface show up. Where is my eth0?

2. Then, I check the network status:

$ sudo service networking status

It said it could not bring up the eth0 interface because it find no interface name eth0 on the server.

3. Finally, I tried and "the thing" shown up:

$ sudo ifconfig -a


4. And because I statically assigned the interface's configuration so I have to go in and change it to reflect the new name of the interface:

$ sudo nano /etc/network/interfaces

auto ens192
iface ens192 inet static


Friday, November 11, 2016

CYGWIN - Starting sshd: Privilege separation user does not exist

The other day, I could start the CYGWIN sshd service on my Windows Server 2008 R. It said:

"The cygwin sshd service started and then stopped"

I then looked at the logs at C:\cygwin64\var\log\sshd.log:

"Privilege separation user sshd does not exist"

I did the following and was able to start cygwin sshd:

1. Edit the file /etc/passwd and add the below line:

sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin

2. and the below line in the /etc/group file:


3. Then I can start CYGWIN sshd service again.