Deployer: Symlinks should be relative

[nakashu]

On one shared host I found an issue with current symlinks creation.

Currently generated symlinks are absolute, and it causes problems with apache rewrite on a shared
environment

When I change the symlink cretion to relative ln -srnf ... everthing works fine.
I can make a PR, but wanted to check if this wasn't by design.
Also when making the changes, should this be configurable or make it relative by default?

[oanhnn]

Thank for feedback.
But, current absolute symlinks are working with me and more people. I don't think problem is absolute or relative. Your apache config may be have a incorrect. Can you post a example to here?
When change from absolute to relative, it may be have other problem. Did you test that enviroments ? (NGINX, APACHE share host or not, ... )

[nakashu]

@oanhnn absolute symlinks worked for me very well on my own servers.
On this particular shared host I dont have access to the configuraion file. I have only htaccess that I can manage, where I rewrite the path to the /current directory

Options +FollowSymLinks
RewriteEngine on

RewriteRule ^(.*)$ /current/$1 [L]

The problem with absolute links there is that the real path to the web dir is something like this

/nfs/something/more/letter/shard/random/stuff/home/my.domain.com/web/

Apache and scripts dont have access to anything before/home` also those parts tend to change.

I will test the relative recipe in other environments and get back with the results, but so far the recipe work on the shared host, with everything: deploy, rollback, consequent deploys, shared files and dirs.

thanks.

[oanhnn]

@nakashu
Can you try:

/path/to/home/my.domain.com/web/.htaccess         <== file htaccess 1
/path/to/home/my.domain.com/web/current/.htaccess <== file htaccess 2

# file htaccess 1
Options +FollowSymLinks
RewriteEngine on

RewriteRule ^(.*)$ /current/$1 [L]

# file htaccess 2
Options +FollowSymLinks
RewriteEngine on

RewriteBase /

[nakashu]

@oanhnn thanks tried that already, with various variations like 20 :)

the problem there is that the absolute symlink got permission problems, that I can see in logs, so it would be something like openbasedir thing.

As I said will try with different setups, and come back with results.
So far from the discussion I assume, that even if I will make the PR, relative symlinks should be an configurable option per enviorment.

[oanhnn]

Ok. You can make PR and we will make discussion about it. I think this is a problem of config apache.

[nakashu]

@oanhnn look around if capistrano got these problems in the past too, and they had.

It totaly depends on the configuration on the shared host, but problems like mine are not that uncommon.

for reference:
https://discourse.roots.io/t/capistrano-symlinks-and-mediatemples-gridserver/1313/8
http://poweredbycoffee.co.uk/using-capistrano-composer-deploy-mediatemple-gridservice/

[x3ro]

I have the same problem, but a different cause :D For me the issue with absolute symlinks is that they break in the backup, which is pretty annoying. Is there a specific reason that one would prefer absolute symlinks over relative ones?

[antonmedv]

What's a task for next Deployer v4. :+1:

[kszymukowicz]

I can confirm.
We have two shared hostings where absolute symlinks are not working.

[ju1ius]

I confirm too.

It's a quite common practice to chroot sftp shells and make directories accessible using bind mounts.
For example your htdocs directory could be /var/www, but show as /htdocs inside the sftp shell.
If you then do a ln -s /var/www/foo /var/www/bar, then for sftp /htdocs/bar is a broken link, since /var/www/foo simply does not exists inside the chroot.

Now if you have a recipe that does a ln -sf {{deploy_path}}/current/htdocs /var/www, your entire web root becomes inaccessible by ftp.

IMO a good solution would be to make all symlinks relative to {{deploy_path}}, e.g:

within('{{deploy_path}}', function () {
  run('ln -srfn releases/{{release_name}} current');
});

[iandunn]

One thing that the PR will probably need to take into consideration is that the -r parameter for ln wasn't added until rather recently, in 8.16. Media Temple and DreamHost are both still on 8.13, and I doubt they're the only ones.

Adding -r in a version that doesn't support it will cause the command to fail.

[iandunn]

I was able to get this working for my use case with some basic string manipulation.

That's probably isn't robust enough to cover everyone's use cases, but it might be a good starting point for a PR, if anyone is interested.

[antonmedv]

May be detect is -r avaiable from —help command?

[iandunn]

May be detect is -r avaiable from —help command?

That's a good thought, but since ln -r isn't widely available yet, won't the solution need to accommodate environments that doesn't support it?

If that's the case, then it seems like it'd be easier to just avoid -r altogether, until it's widely available.

i.,e., it seems like this:

// @todo migrate to ln -srnf when coreutils 8.16 is widely available on shared hosts 
run( custom_function_to_generate_relative_symlink_command() );

would be simpler than this:

if ( custom_function_to_detect_if_ln_supports_r_param() ) {
  run( "ln -srfn ..." );
} else {
  run( custom_function_to_generate_relative_symlink_command() );
}

[antonmedv]

Done.
Relative symlinks in master branch! Soon in v4.

[vingrad]

@elfet please make new release.

[antonmedv]

@vingrad relative symlinks already released.

[bernhardberger]

Is there a way that I can configure Deployer to use relative symlinks as it breaks our hosting on a managed reseller server too. (v5)

Really don't want to rewrite the whole thing..

[antonmedv]

https://deployer.org/docs/configuration#use_relative_symlink

It's used by default in your system supports it.