-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Symlinks should be relative #503
Comments
Thank for feedback. |
@oanhnn absolute symlinks worked for me very well on my own servers.
The problem with absolute links there is that the real path to the web dir is something like this
Apache and scripts don 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. |
@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. |
Ok. You can make PR and we will make discussion about it. I think this is a problem of config apache. |
@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: |
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? |
What's a task for next Deployer v4. 👍 |
I can confirm. |
I confirm too. It's a quite common practice to chroot sftp shells and make directories accessible using bind mounts. Now if you have a recipe that does a IMO a good solution would be to make all symlinks relative to within('{{deploy_path}}', function () {
run('ln -srfn releases/{{release_name}} current');
}); |
One thing that the PR will probably need to take into consideration is that the Adding |
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. |
May be detect is -r avaiable from —help command? |
That's a good thought, but since If that's the case, then it seems like it'd be easier to just avoid 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:
|
Done. |
@Elfet please make new release. |
@vingrad relative symlinks already released. |
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.. |
https://deployer.org/docs/configuration#use_relative_symlink It's used by default in your system supports it. |
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?
The text was updated successfully, but these errors were encountered: