A site (no composer, else I'd do it there) has a few symlinks inside the container that are required for it to work.
How do I tell ddev to create those symlinks on ddev start?
I'm sure it's right before my eyes, but I don't find it. Google gives me nothing, maybe the answer is too obvious? Do a ln -s on first run?
First, I would probably create the symlink in my repo and check it into git. This would have problems on Windows (but symlinks in general are risky on Windows).
You'll want to use relative symlinks so that the relative path can be followed either inside the container or on the host.
So, use a post-start hook with exec (to do it inside the web container) if you have to:
hooks:
post-start:
- exec: ln -sf ../vendor/bin/behat behat
Or (especially if you're not on Windows) you could also do it on the host with either a pre-start or post-start hook:
hooks:
pre-start:
- exec-host: ln -sf ../vendor/bin/behat behat
Beware that the default directory for exec in the web container is not necessarily the project root, it may be the docroot (as it is with Drupal).
Related
I am upgrading a site and don't want to site-install (composer-install) drush at all, but I need it. I know that on my Drupal 7 project drush8 is installed, but I'd like to use it in my Drupal8+ project as well, without changing the project.
drush8 is installed in the web container as /usr/local/bin/drush8, but on Drupal8+ it's not linked to drush because the recommended technique is to site-install it (ddev composer require drush/drush) but you can just symlink drush8 to /usr/local/bin/drush and you'll immediately have ddev drush working with drush 8.
There are two ways to do this:
Use a custom .ddev/web-build/Dockerfile:
ARG BASE_IMAGE
FROM $BASE_IMAGE
RUN ln -s /usr/local/bin/drush8 /usr/local/bin/drush
Use a post-start hook to do the linking. Add this to your .ddev/config.yaml:
hooks:
post-start:
- exec: ln -s /usr/local/bin/drush8 /usr/local/bin/drush
The first way (Dockerfile) is probably better because it only happens once, whereas the second way (config.yaml post-start) happens every time you do a ddev start.
Note that if you just want to use a site-installed drush that is in a nonstandard location, you can do that using the similar recipe at https://stackoverflow.com/a/69399975/215713
I'm trying to add sqlpackage to a Laravel Sail Docker. While this is normally not really difficult, Sail makes it kinda hard.
I have the following section in my Dockerfile
RUN curl -L https://go.microsoft.com/fwlink/?linkid=2157202 -o /usr/local/bin/sqlpackage.zip
RUN mkdir /usr/local/bin/sqlpackage
RUN unzip /usr/local/bin/sqlpackage.zip -d /usr/local/bin/sqlpackage
RUN rm /usr/local/bin/sqlpackage.zip
RUN echo "export PATH=\"\$PATH:$HOME/usr/local/bin/sqlpackage\"" >> /home/sail/.bashrc
RUN chmod a+x /usr/local/bin/sqlpackage/sqlpackage
First off, I'm not happy with the install path I've chosen (/usr/local/bin). But it's the best I could think of. Any suggestions are welcome.
My second, and more important issue is that I can't add run the echo to the path when installing. The install script can't reach the home path. Would really like a solution for this. But I get this error:
cannot create /home/sail/.bashrc: Directory nonexistent
However it exists. So it's a rights issue for the installing user. Any suggestions are welcome.
cannot create /home/sail/.bashrc: Directory nonexistent
It looks like user sail doesn't exist so
before
RUN echo "export PATH=\"\$PATH:$HOME/usr/local/bin/sqlpackage\"" >> /home/sail/.bashrc
Create user like below
# add user
RUN useradd sail
# and then
RUN echo "export PATH=\"\$PATH:/usr/local/bin/sqlpackage\"" >> /home/sail/.bashrc
Also $HOME is not required, because during build time it become
export PATH="$PATH:/root/usr/local/bin/sqlpackage"
Try below on terminal ( for example I am as root user ):
$ echo "export PATH=\"\$PATH:$HOME/usr/local/bin/sqlpackage\""
export PATH="$PATH:/root/usr/local/bin/sqlpackage"
Similar way during build process it will use current user that is root.
First off, I'm not happy with the install path I've chosen
(/usr/local/bin). But it's the best I could think of. Any suggestions
are welcome.
/usr/local/bin is the location for all add-on executables that you add to the system to be used as common system files by all users. Locally installed software must be placed within /usr/local.
# Used for non-system libraries and executables
/usr/local/bin
usr stands for User System Resources. This is the location that system programs and libraries are stored.
local represents resources that were not shipped with the standard distribution and, usually, compiled and maintained on a per site basis.
bin represents binary compiled executables.
So keep in mind these three
/usr/bin: User commands.
/usr/sbin: System administration commands.
/usr/local/bin: Locally customized software.
/opt is a directory for installing unbundled packages that is packages not part of the Operating System distribution, but provided by an independent source. I usually put all 3rd party packages in /opt
there is a similar question, but the difference here is that I am working on Windows. I am running git on Windows (working in git bash tool) and I have successefully cloned my forked repository. Now I need to make symbolic link and it gives me Permission denied. I can make new dir for example in .git folder and I have also set chmod /R 777 for .git directory, so it seems I have permissions.
I tried to run:
rm -rf hooks and then ln -s ../git_hooks hooks.
You might be running into a basic incompatibility of ln on windows platforms (in this case within MINGW-MSYS). You can replace ln with a version that "does the right thing" on Windows; have a look at this:
Git Bash Shell fails to create symbolic links
I had this issue on Windows and I did a couple of steps to resolve this :
Enabled core.symlinks by modifying git config
git config --edit
Opened Git Bash as an Administrator and executed the git checkout command
This worked for me, hope it helps someone.
If you have are using Git for Windows SDK, you can install winln using the pacman package manager by running: pacman -Su winln
Then you can run: winln -s target link, it will check that you have SeCreateSymbolicLinkPrivilege, otherwise it will fail. This is equivalent to running Window's mklink.exe.
I am surprise Git for Windows, does not ship with winln vs an ln command that does a copy without telling you that it did a copy.
When installing git-bash for windows, there is an option called "Enable symbolic links". When I installed git-bash with that option I had the same issue as OP. So I installed the same setup (git-bash) again with that "Enable symbolic links" option unchecked. Then my issue was resolved.
If you are using a local web server on Windows (OpenServer, Laragon, Local), then start the server as an administrator. It worked for me
I have a CI 2.0 project under VCS w/ the repo hosted on my server. Currently I have a bash script that I've posted below. It checks out the source code, moves some files around, and restarts the server to reflect the updated web site.
Is there anything wrong w/ my current method? Does anyone else have any other recommendations on other tools I could use or ways to do it better? Thanks!
# Stop apache while we update the server, and export our svn repo to a tmp dir
sudo /etc/init.d/apache2 stop
svn export file:///home/steve/repository/example/trunk /home/steve/example_dev/
# Prepare the public_html folder for the update, and remove the tmp directory
rm -rf /home/steve/public_html/example.com/public/
mv /home/steve/example_dev/ /home/steve/public_html/example.com/public/
rm -rf /home/steve/public_html/example.com/public/license.txt
rm -rf /home/steve/public_html/example.com/public/user_guide
rm -rf /home/steve/example_dev
# Restart apache
sudo /etc/init.d/apache2 start
I work using a local WAMP directory, which stores the directories of my projects (something DreamWeaver automatically does). I then use DreamWeaver to work directly with the live server. So everytime I edit a file it overwrites in my local directory. Changes are made instantly on the live server, which then when I'm ready to commit to my SVN trunk I simply run SmartSVN (or whatever you use) then commit my local WAMP directory to the SVN.
I don't know if it's the best option really, but it's most likely better than rebooting your webserver for changes.
Well I have a found a much simpler way to update my site now. No longer am I restarting Apache either :) Check out my script below.
svn export --force file:///home/steve/repo/example/trunk \
/home/steve/public_html/example.com/public/
We use Capistrano for CI and other PHP deployments. It works pretty well. https://github.com/namics/capistrano-php
I've got a Mac that I can run either the Leopard (10.5) or Snow Leopard (10.6) version of OS X on. I'm using it to do web development/testing before publishing files to my production host.
On the production host my site's doc root is under the home directory (e.g. /home/stimulatingpixels/public_html) and I'd like to duplicate that location on the Mac. Unfortunately, their is a hidden and lock placeholder on the Mac that looks like a mounted drive with nothing in it sitting in the /home location.
I know from experience that it's unwise to move this and drop in your own /home directory because upgrades can cause it to be erased (and it doesn't get stored in the TimeMachine backup, by the way).
So, the question, is there anyway to safely use /home on a Mac either Leopard or Snow Leopard?
(Note: I realize this is very Mac specific and will be asking it in an Apple forum as well. Just wanted to ask here in addition to cover all the bases.)
Update: To help describe why I want to do this, in addition to the front end web site, I've got a series of scripts that I'd like to run as well. One of the main goals with being able to use the /home directory (and more specifically the same path from the servers root) is so that can use the same output paths on the development mac as well be used on the production server. I know there are ways to work around this, but I'd rather not have to deal with it. The real goal is to have all the files on the development Mac have the same filepath from the / root of the directory tree as the production server.
Another Update: The other reason that I forgot to mention earlier for this is setting up .htaccess paths when using basic authentication. Since those paths are from the file system root instead of the website docroot, they end up going through "/home" when that's part of the tree.
NOTE: As of 2015, I no longer use or recommend this method. Instead I use Vagrant to setup virtual machines for dev and testing. It's free, relatively easy, and allows better matching of the production environment. It completely separates the development environment and you can make as many as you need. Highly recommended. I'm leaving the original answer below for posterity's sake.
I found an answer here on the Apple forums.
In order to reclaim the /home directory, edit the /etc/auto_master file and comment out (or remove) the line with /home in it. You'll need to reboot after this for the change to take effect (or, per nilbus' comment, try running sudo automount -vc). This works with Mac OS X 10.5 (Leopard). Your millage may vary for different versions, but it should be similar.
As noted on that forum post, you should also be aware that Time Machine automatically excludes the /home directory and does not back it up.
One note of warning, make sure to back up your /home directory manually before doing a system update. I believe one of the updates I did (from 10.6 to 10.7 for example) wiped out what I has stored in /home without warning. I'm not 100% sure that's what happened, but it's something to be on the lookout for.
Putting it all together from the tips and hints above:
edit /etc/auto_master # comment out the line with /home in it.
remount:
sudo automount -vc
make a softlink to the mac-ified dir:
sudo ln -s $HOME /home/$USER
At that point, your paths should match-up to your production paths. env vars will still point to /Users/xxxx, but anything you hard-code in a path in your .bashrc --or say, in ~/.pip/pip.conf-- should be essentially equivalent. Worked for me.
re: "The real goal is to have all the files on the development Mac have the same filepath from the / root of the directory tree as the production server."
On production, my deploy work might happen in /opt/projects/projname, so I'll just make sure my account can write into /opt/projects and go from there. I'd start by doing something like this:
sudo mkdir /opt/projects
sudo chown $USER /opt/projects
mkdir /opt/projects/projname
cd /opt/projects/projname
With LVM, I'll set a separate partition for /opt/, and write app data there instead of $HOME. Then, I can grow the /opt file system in cases where I need more disk space for a project (LVM is your friend.)
I tried it on Yosemite (OS X 10.10.1) the sudo automount -vc didn't work, I had to use sudo umount /home.
Therefore my workflow would be:
# comment out line starting with /home
sudo vi "+g/^\/home/s/\//#\//" "+x" /etc/auto_master
sudo umount /home
# link actual home directory (/Users/<user>) to new 'home' (/home/<user>)
ln -s $HOME /home/$USER
I adapted the previous solutions to Big Sur (macOS 11.2), which is a bit more complicated due to the APFS file system changes. I managed to change /home by following these steps:
As recommended by Alan W. Smith, comment out the /home entry in /etc/auto_master.
As suggested by Marco Torchiano, run
sudo umount /home
Since /home is currently a read-only link to /System/Volumes/Data/home, you have to change the latter. I did it with the following commands:
cd /System/Volumes/Data/
sudo rmdir home
sudo ln -s <some other directory> home
Why don't you just run MAMP and use the Sites directory? You can develop off localhost and just have a bunch of aliases for your sites. I'm not sure why you specifically need to use the home directory.
EDIT:
Ok, I think you are going about solving your problem the wrong way.
If it's HTML paths you are worried about, the begin everything with a slash "/" which will default it to the home dierectory.
If it's the references in your PHP, then you need to create a global (or similar) and set it as the root of your site. Then you can reference everything from the global and when you move the site from dev to production all you need to change is the global.
Trying in a round-about way to develop from /home because it looks more like the production server is a bad idea.
Install MAMP, create the global somewhere high in the hierarchy and start re-referencing. It'll be less pain in the long run.