I am trying to use docker on Windows 10 via boot2docker and VB.
boot2docker ssh
boot2docker ip => 192.168.59.103
docker run -tip 80:80 tutum/apache-php bash
ping 192.168.59.103 from host machine
It is sounds working pretty good exepts :
via the browser, when I go to http://192.168.59.103 the page is not found
Do you have some idea about my issue ?
Thanks.
Edit : my logs
docker#boot2docker:~$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ecb75ba8f5f9 tutum/apache-php "/run.sh" 20 minutes ago Up 20 minutes 0.0.0.0:80->80/tcp ecstatic_galileo
docker#boot2docker:~$ docker logs ec
==> /var/log/apache2/access.log <==
==> /var/log/apache2/error.log <==
==> /var/log/apache2/other_vhosts_access.log <==
==> /var/log/apache2/error.log <==
[Mon Aug 17 10:18:25.361931 2015] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.7 (Ubuntu) PHP/5.5.9-1ubuntu4.11 configured -- resuming normal operations
[Mon Aug 17 10:18:25.363857 2015] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'
docker#boot2docker:~$
You've told the container to run a bash shell, not a web server.
Try changing the run command to:
docker run -d -p 80:80 tutum/apache-php
Then accessing the URL. The should run the default command for the container, which will presumably start apache. In your case you overrode the default command to be "bash", which won't start apache.
Related
Environment:-
Ubuntu 20.04.4 LTS
$ apache2 -version
Server version: Apache/2.4.53 (Ubuntu)
Server built: 2022-03-14T15:01:21
Problem:-
Everything was working fine, Suddenly started getting below errors on browser when i access http://160.55.56.28/artifacts and terminal.
Forbidden
You don't have permission to access this resource.
Apache/2.4.53 (Ubuntu) Server at 160.55.56.28 Port 8080
$ curl http://localhost/artifacts
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access this resource.</p>
<hr>
<address>Apache/2.4.53 (Ubuntu) Server at 160.55.56.28 Port 8080</address>
$ sudo tail -f /var/log/apache2/error.log
[Thu Nov 10 09:11:46.009901 2022] [core:error] [pid 517203:tid 139940436375296] [client 160.55.56.28:44400] AH00037: Symbolic link not allowed or link target not accessible: /var/www/html/artifacts
[Thu Nov 10 09:11:46.721754 2022] [core:error] [pid 517203:tid 139940302157568] [client 160.55.56.28:44404] AH00037: Symbolic link not allowed or link target not accessible: /var/www/html/artifacts
[Thu Nov 10 09:11:46.886521 2022] [core:error] [pid 517203:tid 139940419589888] [client 160.55.56.28:44406] AH00037: Symbolic link not allowed or link target not accessible: /var/www/html/artifacts
In /etc/apache2/apache2.conf have below.
<Directory /var/www>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Require all granted
</Directory>
$ ls -lsa /var/www/html/artifacts
0 lrwxrwxrwx 1 admin admin 55 Nov 10 09:03 /var/www/html/artifacts -> /home/admin/.mits/packages/releases
Already executed chown -R admin:admin /var/www/ and chown -R admin:admin /home/admin/.mits/packages/releases, Post service restart still same problem persisting.
Please suggest me possible solution. Thanks!
The following helped to solve my problem.
$ sudo chmod -R +x /home/admin/
$ sudo service apache2 stop
$ sudo service apache2 start
I have an issue in my SSH session with a docker container.
Actually can't execute any command because of a running process that never gives me hand on the terminal, see output:
[Thu Apr 02 19:39:46.056749 2020] [mpm_prefork:notice] [pid 7] AH00163: Apache/2.4.43 (Unix) PHP/7.3.16 configured -- resuming normal operations
[Thu Apr 02 19:39:46.057465 2020] [core:notice] [pid 7] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
Dockerfile install Apache on Alpine and ends:
ENTRYPOINT [ "/opt/entrypoint.sh" ]
entrypoint.sh:
/usr/sbin/httpd -D FOREGROUND
Any hint how I can get my SSH session working and gives me hand to execute other commands? Thank you.
The container paradigm does not promote usage of things like ssh servers. The core concept is that you are only hosting a single isolated process inside the container, in your case 'httpd'.
in other words, there is no ssh server running inside the apache container, it is only hosting the web server process.
You can use a command like docker exec <container_name> <command>, to execute another process in the same container. For example:
docker exec myhttpd ls -la
Which will list the content of the configured working directory in the container.
docker exec will connect the stdout and stderr in your current terminal session to the stdout and stderr of the container, and execute your command in the environment of the container.
This is a good solution for trouble shooting and trying things out. But look for alternatives if you are seeking to permanently change the environment of your contained application. Such as using the Dockerfile.
If you supply some more information about your usecase, I will be happy to make a suggestion.
Actually moving command from my dockerfile to the procfile provided by my hosting provider solved the issue.
Dockerfile after this change:
FROM alpine
# install apache
# other installation requirements
EXPOSE 80
# commented the line below
# ENTRYPOINT ["/opt/entrypoint.sh"]
And moved the last instruction to Procfile. After this change the process will be a service published from my container and not an entrypoint that will be executed each time the image built or restarted.
I followed the guide on https://blog.ssdnodes.com/blog/installing-nextcloud-docker/ and got the docker containers running.
I changed the port mappings of nextcloud-proxy to 7443:443, 780:80, since my server already has an apache running.
When I open the page foo.bar.com:7443, it shows me a server error 500 page by nginx.
docker logs --details nextcloud-proxy only shows me, that the error-500-page was successfully delivered.
docker logs --details nextcloud-app does not show any errors regarding the request. It only shows some messages during startup:
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.19.0.5. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.19.0.5. Set the 'ServerName' directive globally to suppress this message
[Mon Mar 04 19:23:01.413561 2019] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.25 (Debian) PHP/7.2.15 configured -- resuming normal operations
[Mon Mar 04 19:23:01.413653 2019] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'
It is pretty clear, that there is an error with apache or php (both should be logged by nextcloud-app). But I need to see the error log entries. How do I do this?
Logs are redirected to nextcloud's data folder.
From your nextcloud's root, try with:
$ tail nextcloud/data/nextcloud.log
(or the folder you set for data storage).
It's even better if you run the nextcloud with this switch to mount it to a folder on your host, edit config/config.php to have finer-grained logs through setting loglevel, the run tail -f data/nextcloud.logs
docker run -v ~/Projects/nextcloud:/var/www/html -d -p 8080:80 nextcloud
<?php
$CONFIG = array (
'htaccess.RewriteBase' => '/',
...
...
...
'loglevel' => 0,
);
Restart the docker image by running docker restart YOUR_INSTNANCE_ID
Then docker exec -it YOUR_INSTNANCE_ID bash -c "tail -f /var/www/html/data/nextcloud.log"
In my case, it helped to configure Nextcloud to use stdout instead of a dedicated logfile for its logging output.
This allows you to see all the logs instead of just the php fpm output in the if you execute docker logs <yourcontainerid> or view it in Portainer or some other management software.
Just add the following to your config.php
"logfile" => "/dev/stdout",
I am trying to configure Apache httpd.conf (on my CentOS 6.4) to allow access to my user directory (i.e. ~me/public_html/index.html).
I changed the original httpd.conf (i.e. out-of-the-box) as follows:
[root#myhost www]# diff /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.orig.out-of-the-box
366c366
< #UserDir disabled
---
> UserDir disabled
373c373
< UserDir public_html
---
> #UserDir public_html
This should in principle provide access to http://myhost/~me but instead, I am getting the dreaded error:
You don't have permission to access /~me on this server.
I checked the file /var/log/httpd/error_log and, sure enough, it reads:
(13)Permission denied: access to /~me denied
The first weird thing I noticed is that a / is prepended to ~me.
Where does that leading / come from?
Is it only a "red herring"?
Or is this pointing to the root cause of the problem (i.e. something else I need to modify in httpd.conf)?
Most importantly, since I know that my ~me/public_html is has world-readable permissions, how do I troubleshoot a problem like this?
Is there a way to find out why "access to /~me denied"?
SELinux?
httpd.conf?
directory permissions?
all of the above?
Update 1, answering the 2 questions in the comments by #UlrichSchwarz below:
The home directory does seem to have the 'x' permission:
[root#myhost ~]# ls -lad /home/me
drwxr-xr-x. 33 me me 4096 Feb 8 16:30 /home/me
SELinux info on public_html:
[root#myhost ~]# ls -Z -d /home/me/public_html/
drwxrwxr-x. me me unconfined_u:object_r:file_t:s0 /home/me/public_html/
Update 2, after I verified that this is indeed an SELinux issue (thanks to the tip by #Scolytus):
I ran the command:
chcon -R -t httpd_user_content_t /home/me/public_html/
Still no go.
[root#myhost ~]# ls -Z -d /home/me/public_html/
drwxrwxr-x. me me unconfined_u:object_r:httpd_user_content_t:s0 /home/me/public_html/
Then I ran "Allow HTTPD to read home directories" from the command line:
setsebool -P httpd_enable_homedirs=1
Still no go.
/var/log/httpd/error_log now shows (in addition to the (13)permission denied error) the following:
[notice] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
[notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[notice] Digest: generating secret for digest authentication ...
[notice] Digest: done
[notice] Apache/2.2.15 (Unix) DAV/2 configured -- resuming normal operations
Perhaps the problem lies in the discrepancy between context_system_u and httpd_user_content_t?
What else do I need to do? (without disabling SELinux completely, that is)
Update 3, thanks to information in #lserni's answer, I discovered the ausearch command:
ausearch -m avc --start today
Which provided the following output:
time->Fri Jul 4 09:16:44 2014
type=SYSCALL msg=audit(1404479804.256:1312): arch=40000003 syscall=196 success=no exit=-13 a0=12c2c80 a1=bfeb1d00 a2=a34ff4 a3=2008171 items=0 ppid=5880 pid=5886 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=193 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1404479804.256:1312): avc: denied { getattr } for pid=5886 comm="httpd" path="/home/me" dev=dm-3 ino=2 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir
Huh? Why /home/me and not /home/me/public_html?
Here is the output of ls -Zd /home/me/:
drwxr-xr-x. me me system_u:object_r:file_t:s0 /home/me/
Should I run the chcon -t httpd_user_content_t on /home/me, too?
Continuing to research...
Update 4: Success!
I ran the command:
chcon -t httpd_user_content_t /home/me/
And all is well now.
[root#myhost sa]# ls -Z -d /home/me/
drwxr-xr-x. me me system_u:object_r:httpd_user_content_t:s0 /home/me/
I've seen a slightly different version of the command you gave, supplied by sealert:
SELinux denied access to /var/www/html/file1 requested by httpd.
/var/www/html/file1 has a context used for sharing by different
program. If you would like to share /var/www/html/file1 from httpd
also, you need to change its file context to public_content_t. If
you did not intend to this access, this could signal a intrusion
attempt.
Allowing Access:
You can alter the file context by executing chcon -t public_content_t
'/var/www/html/file1'
Fix Command:
chcon -t public_content_t '/var/www/html/file1'
how do I troubleshoot a problem like this?
Most SELinux-related information is generally in the auditd logs, but you probably want some tool such as sealert to decode it for you. I've done a brief search and came up with this tool that I didn't know of, but seems interesting: SELinux GUI.
Addendum: Some examples with semanage
I can't check immediately, but I recall that commenting out the UserDir disabled isn't the same as enabling!
More specifically, I think you need to include a line in your https.conf file
Userdir enabled me
I am having issue when I select a kick start profile to start installation after PXE boot. On the network installation server (same DHCP server) side I can see the following error in /var/log/messages when I hit this issue.
Nov 13 17:42:30 desktop10 dhcpd: DHCPDISCOVER from 00:0c:29:90:39:53 via eth0
Nov 13 17:42:30 desktop10 dhcpd: DHCPOFFER on 192.168.174.2 to 00:0c:29:90:39:53 via eth0
Nov 13 17:42:32 desktop10 dhcpd: Dynamic and static leases present for 192.168.174.2.
Nov 13 17:42:32 desktop10 dhcpd: Remove host declaration desktopy or remove 192.168.174.2
Nov 13 17:42:32 desktop10 dhcpd: from the dynamic address pool for 192.168.174/24
Nov 13 17:42:32 desktop10 dhcpd: DHCPREQUEST for 192.168.174.2 (192.168.174.10) from 00:0c:29:90:39:53 via eth0
Nov 13 17:42:32 desktop10 dhcpd: DHCPACK on 192.168.174.2 to 00:0c:29:90:39:53 via eth0
Nov 13 17:42:32 desktop10 in.tftpd[20546]: tftp: client does not accept options
Nov 13 17:42:36 desktop10 setroubleshoot: SELinux is preventing in.tftpd (tftpd_t) "read" to ./vmlinuz (httpd_sys_content_t). For complete SELinux messages. run sealert -l 97c61847-7ea2-435f-bede-c95302b034f5**
On server the the selinux security contents
[root#desktop10 ~]# ls -Z /tftpboot/images/ks-rhel-x86_64-server-6-60/vmlinuz
-rw-r--r-- apache apache system_u:object_r:httpd_sys_content_t /tftpboot/images/ks-rhel-x86_64-server-6-60/vmlinuz
Note: desktop10 is RHEL5.6, if I change selinux to permissive then I can proceed with installation.
Can someone help me to sort out this issue? Please let me know if anyone need more info.
Tried as suggested in the comment but no luck
[root#desktop10 ~]# restorecon -Rv /tftpboot/
[root#desktop10 ~]# ls -Z /tftpboot/images/ks-rhel-x86_64-server-6-60/vmlinuz
-rw-r--r-- apache apache system_u:object_r:httpd_sys_content_t /tftpboot/images/ks-rhel-x86_64-server-6-60/vmlinuz
Your files are labeled by 'httpd_sys_content_t' that is not acceptable label for kickstart. It looks you copied the file from an apache directory or you create the file from a web appliaction running on apache.
Relabel directory by default labels:
[root#localhost /]# restorecon -Rv /tftpboot
I think it may work if you try to relabel the directory with tftpd context tftpd_rw_t:
# semanage fcontext -a -t tftpd_rw_t '/tftpboot(/.*)?'
# restorecon -R -v /tftpboot