i use Puphpet to create a local testing vagrant /VM servers and my question is:
I ssh into the VM to change my etc/nginx/conf.d/default.conf config file, but every now and then when either i have to to or choose to i destroy the said vm to mainly re-create or because of issue, i need to repeat the above process of having to update a few config files.
Is there a way say within the vagrantfile or the comman.yaml (puphpet) file to actually add this automatically so i don't need to do this at all.
You could create a shell script in puphpet/files/exec-once[1] to replace your default.conf file.
Related
Drupal 9 requires that the private file directory be set by editing the Drupal settings.php file. However, when I deploy the Drupal by Bitnami container (https://hub.docker.com/r/bitnami/drupal/) on AWS ECS Fargate, I am unable to SSH in to the machine and update the settings.php file.
I'm aware that one solution may be to configure ECS Exec (https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) so that I can tunnel into the container and edit the settings.php file. I'm wondering if that's the ideal solution, or if there is some way to use Docker/ECS commands to potentially:
Copy a custom settings.php file from an outside source (local, or S3)
or
Append text to the settings.php file this container creates after site installation
or
Something I'm not considering
The ultimate goal would be to set a private file directory which I can mount to an EFS system to. So, if there's an EFS related shortcut I'm missing here, that could also prove useful.
I tried looking through the Drupal by Bitnami documentation to see if there was an environment variable or parameter I could set for the private file directory, but I did not see anything.
Thanks in advance,
Jordan
Trying to modify the settings after the container is running is the wrong way to do something like this. That method doesn't scale, and doesn't work in any sort of automated/fault-tolerant/highly-available environment. You shouldn't think of a running docker container as a server that you can then modify after the fact.
If you absolutely want to change the volume path in settings.php then you probably need to create custom docker image, using this Bitnami image as the base, and as part of the Dockerfile for that custom docker image you would either copy a new settings.php file in, or modify the existing file.
However, I'm confused why you need to edit settings.php to change the path. The documentation for the image you are using clearly states that you need to create a persistent volume that is mapped to the /bitnami/drupal path. There's no need to change that to anything else, just configure your ECS Fargate task definition to map an EFS volume into the container at /bitnami/drupal.
I noticed my install of nginx has three folders called
etc/nginx/sites-available
etc/nginx/sites-enabled
etc/nginx/conf.d
Do I really need these if I just want to work directly in the etc/nginx/nginx.conf file and remove the include lines that include these items in nginx.conf? Are these directories used for anything else that would mess things up if I delete them?
No, they are not needed if you define your server blocks properly in nginx.conf, but it's highly suggested. As you noticed, they are only used because of the include /etc/nginx/sites-enabled/*; in nginx.conf.
For curiosity, is there a reason why you do not want to use them? They are very useful; easier to add new sites, disabling sites, etc. Rather than having one large config file. This is a kind of a best practice of nginx folder layout.
Important information:
You should edit files only in sites-available directory.
Never edit files inside the sites-enabled directory, otherwise you can have problems if your editor runs out of memory or, for any reason, it receives a SIGHUP or SIGTERM.
For example: if you are using nano to edit the file sites-enabled/default and it runs out of memory or, for any reason, it receives a SIGHUP or SIGTERM, then nano will create an emergency file called default.save, inside the sites-enabled directory. So, there will be an extra file inside the sites-enabled directory. That will prevent Apache or NGINX to start. If your site was working, it will not be anymore. You will have a hard time until you find out, in the logs, something related to the default.save file and, then, remove it.
In the example above, if you were editing the file inside the sites-available directory, nothing bad would have happened. The file sites-available/default.save would have been created, but it wouldn't do any harm inside the sites-available directory.
I saw below comment in The Complete NGINX Cookbook in NGINX official site !.
The /etc/nginx/conf.d/ directory contains the default HTTP
server configuration file. Files in this directory ending in .conf
are included in the top-level http block from within the /etc/
nginx/nginx.conf file. It’s best practice to utilize include state‐
ments and organize your configuration in this way to keep your
configuration files concise. In some package repositories, this
folder is named sites-enabled, and configuration files are linked
from a folder named site-available; this convention is deprecated.
It is not a must, but a best practise if you host more than one sites on your box.
It will be easier to manage by keep http context and common directives (such as ssl_dhparam, ssl_ciphers, or even gzip settings, etc.) on the nginx.conf so that it applied across all sites.
Keep site-specific server context (such as ssl-certificate, location directives, etc.) at etc/nginx/sites-available/ and name the configuration file as your-domain.conf. The file in etc/nginx/sites-enabled can be just a link to the file to the etc/nginx/sites-available.
I have vagrant setup as my local dev environment. When vagrant is up and I edit my CSS file and look at its source in the browser the new CSS I have written is not in the file and the file is now appended by loads of question marks:
��������������������������
If I do vagrant halt or destroy and then bring it back up the CSS file is fine with the new code visible and formatted correctly and no sign of the question marks. As soon as I edit it again the same things happens. Obviously I don't want to destroy and create vagrant every time I make a CSS change.
Any ideas on this?
Update: I have been told this may be to do with not having NFS installed with vagrant - I am on ubuntu and my files are within an encrypted home directory so I believe NFS doesn't work - any other solutions?
I had lot of problems with not having nfs activated on my VM
What information do you have when you run a 'ls -la file.css' on the file ?
Perhaps you can disable sendfile based on this thread:
JS and CSS files in vagrant not properly encoded when saved outside of the VM
Set enableSendFile to off in httpd.conf.
I usually cannot see .htaccess file because it is hidden, when I login to remote servers with ftp access.
Since I don't have shell access, I usually perform the following steps to edit the file:
I change the settings on my mac (from terminal) to see invisible files
I open .htaccess file on a standard drupal installation and I edit it
I upload it to the remote server and I overwrite the existent one
I disable hidden files on my mac
I was wondering if there is a faster solution
thanks
I often have a separate file in my Drupal root called production.htaccess or something along those lines. Not only does this expose the file in Finder without revealing every single .DS_Store on my system, it also allows me to set separate .htaccess directives for different environments. Then, I just rename production.htaccess to .htaccess after I upload it to the server.
More often than not, the two .htaccess files are identical, but even in that case, I still use this method for the sake of convenience.
The FTP application should have the option to show you hidden files; normally, that is an option available on FTP client applications for Mac OS X.
I need to put a file at this address: http://localhost:51547/file.txt
What folder would I put it in on C:/?
Tony
If I understand your question correctly and you're trying to expose a file via the ASP.NET development server at that location (http://localhost:51547/file.txt) I'm afraid the answer is not quite to your liking.
Basically I don't think you can serve files from the root of the ASP.NET development server (i.e right after the localhost:port/ part - the port is automatically selected by ASP but you can also manually configure it). ASP.NET automatically creates a virtual application path right after localhost:por> and so you're most likely going to be limited to serving files from the virtual application folder. So, assuming you web application name is: "testApp", if you put a file called file.txt in the directory where you're storing the source code for "testApp" it will also become available when you're testing at: http://localhost:port/testApp/file.txt (note the testApp in between the host-name & port, and the file-name)
UPDATE
In light of you comment, here's something you could do. You could try to get a simple HTTP server installed on your development computer and have it serve files on a different port (say port 8000). In that case you would serve file.txt using this secondary HTTP server and it would be accessible at: http://localhost:8000/file.txt.
You could try to install Apache or use IIS which comes with Windows. For Apache, the quickest way to get it going would be to install a WAMP environment. You may also try Lighttpd, and also note that MySQL or PHP are not required at all if you're only serving static files.
Any folder you want. The port designator is specified in IIS itself.
http://support.microsoft.com/kb/149605
I suggest you that if you want to do a site(HTTP) is better to use the port 80 or to do a redirection for another port, remember too that localhoost is a loop back and also take a look at PortForward to check some ports that are used by specific applications and types of servers, and please improve your question.
Regards.