I inside my httpdocs(www), i created a folder called "bin", i put an "test.html" just to display "Hello Stackoverflow", but when I go access the page, i.e http://domain.com/bin/test.html, it says Page Cannot Be Found. But when I move the file to test folder, it display what it should be. Why?
In general, the default config, as part of generally good security practice won't be configured to do anything that isnt normal (like doing stuff other than executing stuff in the bin directory, or stuff that wouldnt normally happen in the base directory). In general, I'd say you should be trying to fit in with this, rather than going against the grain.
Possibly permissions.
chmod 755 /Path/To/Bin/
chmod 644 /Path/To/Bin/test.html
Apart from the evident "check permissions" answer and asuming you are using Apache server you may need to add a .htaccess file with the right permissions in each folder.
Look for .httaccess in other folders and remember to use ls -a ( file begining with dot are hidden by default -a = All )
By the way, it may be a bad practice to put html files in a binary folder.
Related
To solve these issues display in process of installing Drupal as:
Go to your "drupal" folder and make permission 777
Then open "sites" folder and make it 777
Choose "default" folder and make it 777
Open "files" and choose "setting.php" to change permission to 777
You are giving public right to execute read and write files in your directories. Clearly not a good idea.
Check this link for more infos on what to do in production environnement (it also explains basic chmod values wich you seem to not be understanding) : https://www.drupal.org/node/244924
Some normal permissions would be 0644 for files and 0755 for directories. Then i.e. settings.php since there is no need for it to be writable you should fully forbid writing.
If only 0777 "solves" your issue, maybe problem are not permission values but file owner. It happens that you upload files with one (FTP) account Apache is running website with some other, which is not allowed to write over first one. So changing file owner could solve the issue.
Suddenly grep command stopped working. When I did the ls -l ~/grep showing the one file in my home directory.But this file has been present for ages. If I give command which grep --> pointing to /bin/grep and with /bin/grep it is working fine. Can anyone please suggest.
Thanks,
Regards,
Shiv
You can delete the zero-byte file in your home directory. It's not doing anything. (I don't know how it got there.) The problem is that the first entry in PATH, ".", points to whatever directory you're in. So when you're in your home directory, the shell (bash, I assume) looks for grep in the current directory, and finds the file that's there, which can't do anything.
I consider it a bad idea to have "." in your path. It's convenient, and natural if you're coming from the Windows world, but it means that what gets executed can change depending on what directory you're in (as you have now seen). It also means that if you're on a multiuser system, someone can put an executable in one of their directories, and then when you cd into their directory, all of a sudden you're executing their code, which might not be what you want, and could be dangerous.
Instead, remove ".:" (dot colon) from your PATH. When you need to run a script in the current directory, add "./" to its name to execute it. "/bin" and "/usr/bin" should usually be at the front of the list. Some people prefer to put "/usr/local/bin" at the front of the list, or something else.
You can change your PATH by editing .profile or .bash_profile or .bashrc. It depends on how you have your shell set up. Be careful to separate each directory path in PATH with one ":" character.
I'm currently trying to use VVV to develop and test my plugins. My host OS is Win10.
My plugins are in D:\Workshop\projects\vendor\module. I've used this folder structure for a long time, and it is really convenient, especially for use with Composer and friends.
Now I've installed VVV, created a site with VV. I want to test a plugin, the source code of which is in D:\Workshop\projects\XedinUnknown\my-project. So, I create a symlink in D:\Workshop\projects\XedinUnknown\vvv-local\www\my-test-site\htdocs\wp-content\plugins that points to that project's folder. Alas, it doesn't work. If I SSH into VVV and ls /srv/www/my-test-site/htdocs/wp-content/plugins, I can see my-project there, but it points to ../../../../../../../XedinUnknown/my-project, which, of course, doesn't exist. If instead of symlink I create a junction, it's just an empty file.
I suspect that this has to do with how the Linux environment handles Windows symlinks, but I'm not entirely sure. Is it possible to make this work somehow? I really don't wanna copy the whole project folder into VVV.
This is also addressed here.
So, it would seem like I've found somewhat of a solution. I added a synched folder, which maps to my projects home. I then create a symlink to that folder from the WP plugins directory, inside the VM.
Step 1 - Add Shared Folder
This should be done in a Customfile as explained here. This file should go into the same directory as the Vagrantfile, e.g. it will become the Vagrantfile's sibling. In my case, if you're following along from my question, it is in D:\Workshop\projects\XedinUnknown\vvv-local. Anything put here becomes global for the whole of VVV. This also gives you the ability to use different combinations of your projects in different websites. Add these contents to your Customfile, creating it if it does not exist.
config.vm.synced_folder "D:/Workshop/projects", "/srv/projects", :owner => "www-data", :mount_options => [ "dmode=775", "fmode=774" ]
Of course, you should replace D:/Workshop/projects with the path to where you store your projects. Note the forward slashes (/). This works on Win/Nix. For a Windows-only configuration, I suspect you'd have to replace them with \\, because this is an escape sequence.
Step 2 - Add Link to Project
This should be done in your site's vvv-init.sh file. In my case, this file was in D:\Workshop\projects\XedinUnknown\vvv-local\www\my-test-site\, because I want to create this symlink specifically for the my-test-site site. Please note that your VVV path will probably be different, and it doesn't have to be inside the projects directory. It's wherever you cloned VVV into. Add the below lines to your site's vvv-init.sh file.
if [ ! -f "htdocs/wp-content/plugins/my-project" ]; then
echo 'Creating symlink to plugin project...'
cd ./htdocs/wp-content/plugins
ln -s /srv/projects/XedinUnknown/my-project my-project
cd -
fi
In the above snippet, change the path to your desired project path, keeping in mind that /srv/projects/ now maps live to the projects root in your host OS. You can also replace the second occurrence (last word) of my-project in ln -s /srv/projects/XedinUnknown/my-project my-project with whatever you want. As long as you don't change it later, your plugin should not suddenly get de-activated.
Also, from what I understood, vvv-init.sh runs during provisioning, not every time the machine is brought up. So, if you want to run the code in there, you have to run vagrant up --provision from the VVV directory. If you don't want to provision, you can run it manually. SSH into VVV with vagrant ssh, then cd /srv/www/my-test-site (replace my-test-site with name of your site), and run . vvv-init.sh.
Afterword
I am quite new to Bash scripting, and I don't know if my solution is the best one, so please feel free to suggest better versions of the Bash script. I also don't know Ruby, and am new to Vagrant, so please feel free to suggest improvements to the Customfile - this is in essence the same as the Vagrantfile.
One possible issue that I can anticipate with this solution (and this is inherently by design of the filesystem architecture) is that if WordPress decides to make changes to your plugin, e.g. if you run a WP update, it will effectively delete all files in your project, including the repository. So, on the testing site I would recommend using something like this. I am in no way associated with this plugin.
So this doesn't seem like a terribly complicated question I have, but it's one I can't find the answer to. I'm confused about what the -p option does in Unix. I used it for a lab assignment while creating a subdirectory and then another subdirectory within that one. It looked like this:
mkdir -p cmps012m/lab1
This is in a private directory with normal rights (rlidwka). Oh, and would someone mind giving a little explanation of what rlidwka means? I'm not a total noob to Unix, but I'm not really familiar with what this means. Hopefully that's not too vague of a question.
The man pages is the best source of information you can find... and is at your fingertips: man mkdir yields this about -p switch:
-p, --parents
no error if existing, make parent directories as needed
Use case example: Assume I want to create directories hello/goodbye but none exist:
$mkdir hello/goodbye
mkdir:cannot create directory 'hello/goodbye': No such file or directory
$mkdir -p hello/goodbye
$
-p created both, hello and goodbye
This means that the command will create all the directories necessaries to fulfill your request, not returning any error in case that directory exists.
About rlidwka, Google has a very good memory for acronyms :). My search returned this for example: http://www.cs.cmu.edu/~help/afs/afs_acls.html
Directory permissions
l (lookup)
Allows one to list the contents of a directory. It does not allow the reading of files.
i (insert)
Allows one to create new files in a directory or copy new files to a directory.
d (delete)
Allows one to remove files and sub-directories from a directory.
a (administer)
Allows one to change a directory's ACL. The owner of a directory can always change the ACL of a directory that s/he owns, along with the ACLs of any subdirectories in that directory.
File permissions
r (read)
Allows one to read the contents of file in the directory.
w (write)
Allows one to modify the contents of files in a directory and use chmod on them.
k (lock)
Allows programs to lock files in a directory.
Hence rlidwka means: All permissions on.
It's worth mentioning, as #KeithThompson pointed out in the comments, that not all Unix systems support ACL. So probably the rlidwka concept doesn't apply here.
-p|--parent will be used if you are trying to create a directory with top-down approach. That will create the parent directory then child and so on iff none exists.
-p, --parents
no error if existing, make parent directories as needed
About rlidwka it means giving full or administrative access. Found it here https://itservices.stanford.edu/service/afs/intro/permissions/unix.
mkdir [-switch] foldername
-p is a switch, which is optional. It will create a subfolder and a parent folder as well, even if parent folder doesn't exist.
From the man page:
-p, --parents no error if existing, make parent directories as needed
Example:
mkdir -p storage/framework/{sessions,views,cache}
This will create subfolder sessions,views,cache inside framework folder irrespective of whether 'framework' was available earlier or not.
PATH: Answered long ago, however, it maybe more helpful to think of -p as "Path" (easier to remember), as in this causes mkdir to create every part of the path that isn't already there.
mkdir -p /usr/bin/comm/diff/er/fence
if /usr/bin/comm already exists, it acts like:
mkdir /usr/bin/comm/diff
mkdir /usr/bin/comm/diff/er
mkdir /usr/bin/comm/diff/er/fence
As you can see, it saves you a bit of typing, and thinking, since you don't have to figure out what's already there and what isn't.
Note that -p is an argument to the mkdir command specifically, not the whole of Unix. Every command can have whatever arguments it needs.
In this case it means "parents", meaning mkdir will create a directory and any parents that don't already exist.
I realize this is a bit of a strange question, but to put a long story short, we have a few Wordpress installs whose files are loaded through a symbolic link (the symlink is in the document root whereas Wordpress is not).
For this to work, I need to have a list of all Wordpress files that are usually loaded directly from the web browser (either by the user or through AJAX), such as: index.php, wp-login.php, (all theme files)* ...
An example of files that are not loaded directly: wp-load.php, wp-config.php, wp-blog-header.php...
[*] Theme files are an exception; they actually exist in the document root.
Edit: You might wonder, what is the point of this? It is so that we can cut down on the extra files on the server; it's useless to have thousands of identical files from each Wordpress website. The wp-content directory has been left there since it's what changes between websites. Am I aware of the consequences of such a set up? I believe I am.
Edit 2:
http://codex.wordpress.org/WordPress_Files
Here is a list of entry points based on require( 'wp-load.php' );
https://github.com/szepeviktor/WPHW/blob/master/wp-entry-points.md
And a Trac ticket about their deficiencies
https://core.trac.wordpress.org/ticket/28364
So far, the following fixes my issue:
ln -s /var/www/vhosts/mainsite/httpdocs/index.php /var/www/vhosts/subsite/httpdocs/index.php
ln -s /var/www/vhosts/mainsite/httpdocs/wp-login.php /var/www/vhosts/subsite/httpdocs/wp-login.php
ln -s /var/www/vhosts/mainsite/httpdocs/wp-admin /var/www/vhosts/subsite/httpdocs/wp-admin
ln -s /var/www/vhosts/mainsite/httpdocs/wp-includes /var/www/vhosts/subsite/httpdocs/wp-includes