Today I was bewildered by a very unusual problem. Maybe this will help someone else with the same problem !

I was running an executable as myself and it was working perfectly. I had to run it as root to access some protected directories, so I used sudo:

sudo myprogram

I got

error while loading shared libraries: libsomething.so: cannot open shared object file: No such file or directory

Ok, this must be because sudo won’t use the LD_LIBRARY_PATH that I defined, so I try:

sudo -E myprogram

Same error… Ok, I will try to check what’s going on as root, with ldd.

sudo bash
export LD_LIBRARY_PATH=/path/to/my/lib/
ldd myprogram
      libsomething.so  -> /path/to/my/lib/libsomething.so
# Ok ! Everything works as expected, I can run the program
./myprogram
error while loading shared libraries: libsomething.so: cannot open shared object file: No such file or directory

ldd finds all necessary libraries, but the executable still fails to run because it cannot find a library ??

Ok, maybe I don’t have the rights to read or execute the library or the directories in its path ?

chmod -R a+rX /mydirectory does not change anything, even though any user can now access the libsomething.so file.

After a LOT of searching around, I found an explanation : if your executable or library is setuid or setgid, because of security implications, LD_LIBRARY_PATH won’t be used !

Finally, I did a find /mydirectory -type f -exec chmod g-s {} \; to remove the setGID bit on all files (but keeping it on directories). SetGid bit was set to force new files to  belong to the directory’s group : it was only necessary to setgid the directories, not the files !

To install a new PPA (for example the KDE backports to have the latest stable KDE on Kubuntu 15.04) on a connection using a proxy for http/https access :

export http_proxy=http://myProxy:port
export https_proxy=http://myProxy:port
sudo -E add-apt-repository ppa:kubuntu-ppa/backport

The “-E” allows sudo to keep the environment variables defined for the proxy access.

To get apt to use the proxy, create a file /etc/apt/apt.conf.d/50proxy :
Acquire::http::Proxy "http://myProxy:port";
Acquire::https::Proxy "https://myProxy:port";


I needed to install a git server with a web interface. I decided to install Gitlab Community Edition. But I had some trouble using it behind a reverse proxy that does SSL termination

• I added a new virtual machine (VM) called GIT to my virtual machines server SERV. It contains a Debian minimal installation.
• I installed the debian package Omnibus Gitlab 7.9 in GIT.
• The VM GIT is connected to a (virtual) private network which allows SERV to access all its VMs.
• Using iptables, SERV redirects port 1212 to port 22 of GIT. This gives me SSH access to GIT. In /etc/iptables/rules.v4
  -A PREROUTING -i eth1 -p tcp –dport 1212 -j DNAT –to-destination 172.16.0.5:22 -m comment –comment “Redirect port 1212 to GIT”
• SERV serves multiple websites using a number of DNS names. For example, mysite.eu and mygit.eu will redirect to SERV’s IP address.
• SERV runs NGINX as a reverse proxy with SSL termination. This just means that each request to https://mygit.eu is received by nginx which decrypts the https request and forwards it to GIT as an HTTP request. Thus, the outside address is HTTPS but from the viewpoint of gitlab, the coming request is HTTP. In /etc/nginx/sites-enabled/default for each server :
  server {
     listen 443;
     root /var/www/;
    server_name mygit.eu;
    index index.html;
    include /etc/nginx/include/basicsslconfig;
    ssl_certificate /etc/nginx/httpskeys/mygit.eu.pem;
    ssl_certificate_key /etc/nginx/httpskeys/mygit.eu.key;
    location / {
      proxy_set_header Host mygit.eu;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-Proto http;
      proxy_set_header X-Forwarded-Ssl on;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_pass http://172.16.0.5:80/;
    }
  }
• To access gitlab website, I just use https://mygit.eu
• SSH access for git : to get this to work, I just set in /etc/gitlab/gitlab.rb gitlab_rails[‘gitlab_shell_ssh_port’] = 1212
  and the SSH URL displayed for a repository is ok and works.
• HTTP access for git : if I set
  external_url ‘http://mygit.eu’
  The lack of https means that the url won’t work.
  But if i use https, gitlab will configure its own nginx as https server and the forwarded http request won’t work.

Workaround : the reverse proxy replies to http requests by redirecting to the https address. So even if the wrong (http) address is displayed, it will still work. In /etc/nginx/sites-enabled/default

server {
listen 80;
server_name mygit.eu;
# Temporary redirect while keeping the same request -> 307. Permanent redirect -> 301
return 301 https://mygit.eu$request_uri;
}

Real solution : there is a new setting (still not available in the debian package) to allow for this according to https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/nginx.md
nginx[‘listen_https’] = false

This should force the GIT nginx server to accept http and not https requests, even if external_url contains https.