Shared folder with vagrant cause invisible characters appending - character

I have a few invisible characters (�) that appear at the end of a javascript document that cause the "illegal character" error in FF or Chrome. I saw different topics about this error, but nothing works for me, and i can't see anything wrong in my document (displaying invisible characters, open it with a hexadecimal editor). This is just driving me crazy.
I use Vagrant with a nginx web server. The document looks clear in the server too (vi + :set list).
Plus, when I get back a clear document from my Git repository, everything works(normal). But each time I want to edit it (like create a new variable at the top of document), I got this error again.
If someone can helps me, thank you.

If you're using the VirtualBox provider, then VirtualBox shared folders are the default synced folder type. These synced folders use the VirtualBox shared folder system to sync file changes from the guest to the host and vice versa.
There is a VirtualBox bug related to sendfile which can result in corrupted or non-updating files. You should deactivate sendfile in any web servers you may be running.
In Nginx:
sendfile off;
In Apache:
EnableSendfile Off
See vagrant docs: http://docs.vagrantup.com/v2/synced-folders/virtualbox.html

It seems that you're using Vagrant.. please take a look at your _Vagrantfile and check the way files are written on the VM filesystem.
cat ~/.vagrant.d/boxes/[YOUR VM NAME]/include/_Vagrantfile
Maybe you are using config.vm.synced_folder try to use NFS:
config.vm.synced_folder "/home/myuser/shared", ".", :nfs => true

Related

Docker - under Windows 10 Pro - Need to map volumes and have them work, not quietly fail

I ran various containers on Two different Windows 10 Pro machines, and thought that I had the data drives mapped correctly, but now I'm finding out that it isn't writing the data there at all. One example was Mongo db, where I mapped /mongodb/database:/data/db I upgraded docker, and when it restarted mongodb.. POOF! no data, I thought that was weird and looked in /mongodb/database and the directory is empty. Thankfully, the app is still in the development phase, and not critical that the data was lost...
the line from the docker compose file:
volumes:
- /mongodb/database:/data/db
Different machine:
I installed Gogs/gogs image, mapping the data:
docker run --name=Gogs-Git -p 10022:22 -p 10080:3000 -v /var/gogs:/Docker/Gogs-GitServer/Data gogs/gogs
Seemed to work perfectly, so I was thinking everything was fine, I pushed a Repo up to it.. and today, I looked at \Docker\Gogs-gitserver\data and no files... so where did it write the data?
I also installed TeamCity, mapping that data.. nope, it has no logs, no data...
This feature seems to just not work at all. I found a reference from 2016 saying I need to look at the 'shared' tab (below general),and check C: to be shared, but well, no, that isn't a tab, so it isn't that.
There is no way someone would write a system that just quietly wrote the data some other place, or didn't bother actually mapping it without giving an error - that would be nuts.
So, there must be some other explanation... One of the machines has Hyper-V enabled in the BIOS, the other one doesn't even support it as far as I know.
I think some of the images are Linux, and some are Windows (TeamCity I'm pretty sure is)
OK, this is interesting... If I look at the volumes, and enter one that is in use, I get this:
The Target looks about like the right path, but I'm not sure about the /backup and the /data on the last two lines, if these are supposed to be directories under that, they don't exist, but if I click on the data tab, I can see the data, it is in Docker, hidden and not shared, in spite of there being a 'target' that points at the right directory... how to I get it to start writing this data correctly to that folder??
I've not confirmed this yet with the above configuration, but I found that for other containers, I needed to specify the path as 'c:/data/MongoDb/Database' when I created the container using that as the path, it worked and I have data there now. I just need to go back and fix all these VMs so they have their data correctly...

three ways to let PHP and a regular user edit the same files

I am a web developer, and for some upcoming projects I would like to use a file-based CMS. This means that many of the files I create at the start must be editable by the PHP user later, but also remain editable for my user (and also the other way around). My PC runs Debian 9, which I love but am not super knowledgeable about, and I have also just set up a local network server with Debian 9 for backups and possibly file sharing. (I'm using Webmin to configure this, which reflects my level of command line skills).
On my online shared hosting server, the PHP user and the FTP user seem to be the same, and 644/755 permissions work fine, this is also recommended by the CMS I'm using. I would like to mimic this on my computer so I don't have to fiddle with permissions all the time. But how do I do this? Currently, my regular user (anna) does not have access to www-data's files and vice versa. Putting them in the same group still means changing file permissions. Making anna the PHP user is a Bad Idea (as far as I understand it) because anna has sudo permissions.
So far I have researched three possible solutions that I don't really know very much about, and I would like to know which is the best route to take.
Develop locally on my computer and use apache-mpm-itk or suPHP to let PHP edit the files (I got that idea from this question on ServerFault).
Develop locally on my computer and rsync the files to my server with grunt-rsync, and somehow get rsync to set the ownership to www-data (another ServerFault thread helping here).
Mount the project's server directory, which is owned by www-data, on my computer with SSHFS and then either edit the files on the server directly or copy them over from my local directory with grunt-copy.
What do you think: from a security and ease of use perspective, which is the best way? Or do you know an even better one?
Thank you for taking the time to read and think about this!
Anna~
I figured it out! I finally ended up reading about running PHP as CGI instead of as an Apache module, and that this would solve my permissions problem. Plus, as far as I understand it, there are no extra security precautions to take when I'm the only one working with it on my local computer.
In case someone comes across this who might find it helpful, here's what I did (basically following these instructions):
I installed php7.0-fpm
Edited /etc/apache2/sites-enabled/000-default.conf and put the following just before </VirtualHost>:
DirectoryIndex index.php
<LocationMatch "^(.*\.php)$">
ProxyPass fcgi://127.0.0.1:9000/var/www/html
</LocationMatch>
I activated the Apache module proxy_fcgi (via Webmin, which apparently does an automatic Apache restart)
In /etc/php/7.0/fpm/pool.d/www.conf I commented out a listen line and put another below like this:
; listen = /run/php/php7.0-fpm.sock
listen = 127.0.0.1:9000
I then restarted PHP-FPM with this command: /etc/init.d/php7.0-fpm restart (a little different from the instructions, I'm on Debian 9). After that, phpinfo() gave me the Server API "FPM/FastCGI".
And finally, I changed the user and group from www-data to anna in three places, twice in /etc/php/7.0/fpm/pool.d/www.conf and then once more in /usr/lib/tmpfiles.d/php7.0-fpm.conf (this last bit may be Ubuntu/Debian specific, my thanks go to Keith for a comment on StackExchange).
And that was it! :-)

sshfs -o follow_symlinks mounts with broken softlinks

Up until a day ago I was perfectly able to mount a drive via sshfs with the follow_symlinks option given.
In fact I set up an alias for this command and used it for several weeks.
Since yesterday, using the same alias the volume still mounts correctly but the all the soft symlinks within that volume are broken.
Logging in using a regular ssh session confirms the symlinks actually are functioning.
Are there any configuration files that may interfere with what I try to do?
I was modifying /etc/ssh/ssh_config and /etc/hosts because I experienced severe login delays when starting an ssh session from a friend's place. But I reverted any changes later on.
Could a wrong configuration in these files cause my issue?
Btw. I'm using Ubuntu 16.04
It turns out that the permissions on the particular machine I was trying to mount the folder from changed over the weekend.
It is now only allowing access to certain folders from within the same network. That is why my soft-links (pointing to now permission restricted content) seemed broken when mounting from my home network.

Change default directory for website in Amazon EC2 Linux instance

I want to be able to install a Zend - based site on Amazon EC2 Linux instance. To be able to do that, I need to have the main directory name as "public" rather than "html" as is default for EC2.
How can I change the path to the site's default directory from /var/www/html/ to /var/www/public/ ?
Thank you in advance for your help!
Oliver is on the right track. You need to do 2 things:
Update the DocumentRoot statement within the httpd.conf file to your new home directory.
Restart your web service for the change to take effect.
So for example, do the following command:
sudo vi /etc/httpd/conf/httpd.conf
Then look for the following line by typing /DocumentRoot + ENTER in the vi editor:
DocumentRoot "/var/www/"
Now just change the document root directory to whatever you want.(In the vi editor, move the cursor where you want it, press i to switch to insert mode, modify the code, then press ESC to get out of insert mode.) You can (and probably should) also change any <Directory statements that immediately follow, as these relax some access standards and shouldn't apply at a level above your web root. For example, you may see this:
#
# Relax access to content within /var/www.
#
<Directory "/var/www">
I recommend changing this to:
#
# Relax access to content within /var/www/html/drupal.
#
<Directory "/var/www/html/drupal">
Changing the comment is purely for consistency should anyone else review your code later. There are probably at least 2 statements that fit this pattern in the file, so look for and change them.
Save your changes when finished by typing :x and pressing ENTER.
Finally, a crucial step: restart your web service! This is a commonly overlooked step. The command will vary based on your server setup, but will probably be very close to:
sudo service mysqld restart
Check your website when finished to make sure it's going to the right default folder when you just use the domain name with no additional folders. Good luck!

How to configure MAMP to serve perl CGI scripts (NOT localhost!)

I'm using MAMP-pro to serve my domain to the outside world.
I'm not a very experienced sys-admin, though I've slogged my way through a few basic things. I know what apache is, and I can read-most-of but not generate-without-guide related .conf files.
I've got a perl script which I've tested from the command line and it works (outputs as desired.)
When I try to access said script from the browser, I get 404.
I've tried placing the script at:
/Users/me/Sites/mydomain.com/htdocs/mycgi.pl
/Users/me/Sites/mydomain.com/cgi-bin/mycgi.pl
/Users/me/Sites/mydomain.com/htdocs/cgi-bin/mycgi.pl
and accessing it as:
http://www.mydomain.com/mycgi.pl
http://www.mydomain.com/cgi-bin/mycgi.pl
and all the various combinations, all to no avail (404.)
The script and its container directory have permissions 755.
So, what other steps am I missing? Are there any good set-up guides? I tried the MAMP-Pro manual, but it is filled with such information as "the cancel button cancels the current operation" and not really anything useful. Google turned up several hits that all seem to talk about how to make this work on localhost, but I'm trying to serve this to the outside world.
Any hints?
Thanks!
The official online documentation has a section on virtual hosts. When creating a host for www.mydomain.com you can choose the DocumentRoot which is called "Disk location" within MAMP PRO. If you still get a 404 error, take a look into the error_log for a more specific reason (i.e., where Apache tries to find the file in question).