Varnish failed after configure - apache

Regards to all,
I installed the varnish on my Ubuntu 20.04 server. On which Magento2 and Apache web services work. When I apply the varnish according to instructions, it will not work. Can anyone help.
Thanks in advance everyone!
https://i.stack.imgur.com/PfQg6.png

I notice that your varnish.service file is owned by vcache and has rw-r--r-- permissions.
I advise you to perform chown root:root varnish.service, because I'm assuming systemd doesn't have the right permissions to open the file.
Please also verify that the service files are hosted inside /etc/systemd/sytem, because one of your screenshots indicates that some of these files are stored in /etc/systemd.
Long story short, systemd will try to start services using the root user. Make sure this user has read and execute permissions to access this file.

This is the configuration..
https://i.stack.imgur.com/I0f2A.png
https://i.stack.imgur.com/1xn8j.png
https://i.stack.imgur.com/5HAF6.png

Related

How can I get access to my Symfony app on my server?

I cloned my Symfony app to my server and when I want to open the website I get the error:
Forbidden
You don't have permission to access this resource.
Apache Server at mywebsite.com Port 80
What does that mean?
I would check the owner of the files in terminal.
I would check vhost file, on my local Ubuntu the location is /etc/apache2/sites-available/
You could check if you didn't miss any important step from the webserver configuration documentation
Configuring a Web Server
like installing the apache Symfony pack or manually set an .htaccess
I had to link my domain to the public folder instead of the root folder
I'm gonna need more information about the system. Which symfony version do you have? Have you seen the loggers? Have you deployed the system on a docker container? Which version of PHP are you using? Maybe you are missing some dependencies.

Put right permission - owner/group to public_html folder

I'm new to WHM, cPanel, and CentOS.
I install WHM then create an account for domain app.example.com and user peter
I point the domain name to right IP address but when I run my website app.example.com I got HTTP ERROR 500
Via SSH I log into the server and I find my previous uploaded code into
/home/peter/public_html
Then I run command sudo chown -R peter:peter /home/peter/public_html
and when I look at folders permission and owner they looks like:
I think my HTTP ERROR 500 is about user permission.
Can please help me to add right privileges to a user or what I need to do to my public_html folder be visible to the world (at browser).
What I need to do?
The best thing to know if it's a permissions problem, a bug in the programming of the web application or to see what really happens, is that you look at the log file of the web server (apache, nginx, the one you use). The log will give you more clues. Could you copy the log output when the error occurs?
It seems some required extensions were not activate or had been removed from your VPS. You should check and install/activate them. Then you can test your website again.
P.S: Sorry for my bad english

My dedicated server accept only 777 for uploads

I don't know if somebody can help me, but i have a dedicated server on linux and the problem is only the 777 rule accepts uploads or write.
if the path of my site is /var/www/ffolder/data/www/mysite.com how i can enable the rule 755 for uploads and write?
best regards!
Just make sure that the owner of /var/www/ffolder/data/www/mysite.com are the same you use to try the upload.
If the upload is made by some script ran by Apache or nginx, the user owning the directory must be the same user used to start the webserver.

Wordpress: Installing Plugin error -> Could not create directory

this has been asked again and again, but none of the solutions I found actually works for me. I'm testing a new server (Ubuntu server 14.04) and have gone through the whole installation process of the various required software. So far I can access my internal web page via
http://myInternalIP/wordpress/
I added there a dummy post and it looks ok.
Now I wanted to add a plug-in, but I'm having major trouble with that.
So here is what I have done.
I added a new user called ftps that has it's home dir in
/usr/share/wordpress/
and this is part of
~$ groups ftps
ftps : ftps www-data
When I try to add a plug-in, all goes well until I get the following message:
Downloading install package from https://downloads.wordpress.org/plugin/wordpress-importer.0.6.1.zip…
Unpacking the package…
Could not create directory.
Return to Importers
So the general answer I found in many posts, is that this is a permission issue. Fine. Well I'm fighting with the permission issues since xx hours. So here is a brief summary of what I've done:
I've tried changing ownerships and groups around (www-data, my user name, ftps). It did not work.
I've changed permissions to 777 to all the wordpress directory in /usr/share/wordpress.
I've tried the following commands:
sudo -u helder touch /usr/share/wordpress/wp-content/plugins/test.txt
sudo -u ftps touch /usr/share/wordpress/wp-content/plugins/test.txt
sudo -u www-data touch /usr/share/wordpress/wp-content/plugins/test.txt
All of these commands generated a file succesfully in the specific directory.
My feeling is that permissions are not the issue, but I might be wrong... what should I look out for?
Thanks
I had to enable write_enable=YES in the file vsftpd.conf.
If you are using vsftpd as your FTP server and have enabled passive connections, you need to add pasv_promiscuous=YES to /etc/vsftpd/vsftpd.conf.

Drupal 7 Login can't view admin bar, Fresh Install via Drush on CentOS 6.3

I've spent quite a few hours trying to figure out what the problem is. The issue is:
Login works but the page doesn't change once I log in as admin. I know that the login works because wrong credentials generate an error. I do not even see the administrative toolbar. No other pages exist on the page, but if I am to, say, input ?q=admin, on user/1, it will go 'Access Denied'
What I've done:
cleared cache and cookies many times
have checked that mod_rewrite works
the cookie path on the drupal settings.php is / and not \
.htaccess is on the drupal root directory, exactly as provided by
drupal.org
in httpd.conf, I have written a new directory and AllowOverride=All
(*note: the parent directory has AllowOverride=None)
Clean URL's are enabled via drush vset
What I suspect the problem is, but don't know how to solve it:
Proxy?
Some permissions that need to be configured on some files/directories
What I have:
CentOS 6.3
Apache 2.2.15
Drush 5.9
Drupal 7.22
Thank you in advance
I can't imagine that this would be a permissions issue, but if it were, you could just start by doing (and btw, I would NEVER recommend doing this on a production server):
cd /<path_in_which_drupal_root_sits>
chown -R apache:apache <drupal_root>
chmod -R 777 <drupal_root>
You might need to sudo to do these, and you will definitely want to bring the chmod permission back down to 775, 755 or 644 as is appropriate to the directory/sub-directory once you're done testing.
This will probably not solve your issue outright, but it will at least help you to eliminate permissions as an issue.
To test proxy issues, you might try installing lynx (command-line http client), and try accessing your site through it using localhost. You should be able to login, and if you get a different result that way than via remote access, you might indeed have some weird proxy or other network issue that's interfering.
Lastly, and this might actually be the most helpful bit here, you ought to inspect your headers before, during and after the login process. You can do this using FireBug or Developer Tools or the like. And, of course, check your Apache access and error logs for anything unexpected or out of the ordinary.
Most likely, though, you just need to reinstall and try it again.
Turns out that it was a SELinux problem. I found out that if I logout via the logout URL and then use https on my website, I can login and use it properly. I needed to reinstall the certificates and setup the security... Thanks for everyone's help.