I'm having trouble getting our system up and running using HTTPS.
I have created a keyfile from our wildcard certificate and placed the keyfile in our ./conf directory:
473 zbeckman:glimpulse-server$ ll conf
total 72
drwxr-xr-x 9 zbeckman staff 306 Sep 7 09:26 ./
drwxr-xr-x 22 zbeckman staff 748 Sep 7 09:32 ../
-rwxr-xr-x 1 zbeckman staff 1213 Sep 7 09:26 application.conf*
-rw-r--r-- 1 zbeckman staff 1374 Sep 7 08:49 glimpulse.keystore
-rw-r--r-- 1 zbeckman staff 1439 Aug 9 15:58 logback.xml
-rwxr-xr-x 1 zbeckman staff 5206 Aug 8 15:36 routes*
-rw-r--r-- 1 zbeckman staff 575 Apr 29 18:55 ws.conf
474 zbeckman:glimpulse-server$
And I have added the following to our ./conf/application.conf file, as per instructions in the Play Configuring HTTPS page:
play.server.https.keyStore.path = "./conf/glimpulse.keystore"
play.server.https.keyStore.password = "xxxxxxxxxxxxx"
And finally, I'm using -Dhttp.port=disabled -Dhttps.port=9000 to try and start the server, but it refuses to start.
Here are the results. Note the last line of output:
472 zbeckman:glimpulse-server$ ./activator start -Dhttp.port=disabled -Dhttps.port=9000
[info] Loading project definition from /Users/zbeckman/Projects/Glimpulse/Server/project/glimpulse-server/project
[info] Set current project to Glimpulse (in build file:/Users/zbeckman/Projects/Glimpulse/Server/project/glimpulse-server/)
[warn] The start command is deprecated, and will be removed in a future version of Play.
[warn] To run Play in production mode, run 'stage' instead, and then execute the generated start script in target/universal/stage/bin.
[warn] To test your application using production mode, run 'testProd' instead.
[info] Wrote /Users/zbeckman/Projects/Glimpulse/Server/project/glimpulse-server/target/scala-2.11/glimpulse_2.11-1.0-SNAPSHOT.pom
(Starting server. Type Ctrl+D to exit logs, the server will remain in background)
Must provide either an HTTP or HTTPS port
473 zbeckman:glimpulse-server$
As far as the keystore goes, I used the Java keytool to generate the store, based on our wildcard domain certificate:
keytool -import -alias tomcat -keystore glimpulse.keystore -trustcacerts -file star_glimpulse_com.crt
That seemed to go just fine, and the keystore was generated without any errors or warnings.
You could try to run it like this:
./activator "start -Dhttp.port=disabled -Dhttps.port=9000"
The quotes may be required to make sure the parameters get passed to the start command the right way.
Simply add this to your application.conf:
https {
# The HTTPS port of the server.
port = 9001
}
and your app will listen on port 9001
Related
I'm trying to connect to MariaDB with Google App Script.
I've been following this post, and these instructions and used this advice to get the certs setup.
const server = 'x.x.x.x'; //not my actual ip
const port = 3306;
const dbName = 'myDbName';
const username = 'googleusername';
const password = 'hunter2';
const url = 'jdbc:mysql://'+server+':'+port+'/'+dbName+'?useSSL=true';
const serverSslCertificate = '-----BEGIN CERTIFICATE-----\n'+
'zxcv1231223123'+
.... etc ....
'112223334'+'\n'+
'-----END CERTIFICATE-----';
const clientSslCertificate = '-----BEGIN CERTIFICATE-----\n
'+ 'zxcv1231223123'+
.... etc ....
'112223334'+'\n'+
'-----END CERTIFICATE-----';
const clientSslKey ='-----BEGIN RSA PRIVATE KEY-----\n
'+ 'zxcv1231223123'+
.... etc ....
'112223334'+'\n'+
'-----END RSA PRIVATE KEY-----';
var connParams = {
user: username,
password: password,
_serverSslCertificate: serverSslCertificate,
_clientSslCertificate: clientSslCertificate,
_clientSslKey: clientSslKey,
};
When I try to connect, it fails and in MariaDB I can see in the mysql error logs:
2022-10-18 23:01:50 18 [Warning] Access denied for user 'googleusername'#'y.y.y.y' (using password: YES)
And in Apps Script I see
Exception: Failed to establish a database connection. Check connection string, username and password.
If I do:
MariaDB [bitnami_wordpress]> SHOW GLOBAL VARIABLES LIKE '%ssl%' \G
*************************** 1. row ***************************
Variable_name: have_openssl
Value: YES
*************************** 2. row ***************************
Variable_name: have_ssl
Value: DISABLED
*************************** 3. row ***************************
Variable_name: ssl_ca
Value: /opt/bitnami/mariadb/certs/ca.pem
*************************** 4. row ***************************
Variable_name: ssl_capath
Value:
*************************** 5. row ***************************
Variable_name: ssl_cert
Value: /opt/bitnami/mariadb/certs/server-cert.pem
*************************** 6. row ***************************
Variable_name: ssl_cipher
Value:
*************************** 7. row ***************************
Variable_name: ssl_crl
Value:
*************************** 8. row ***************************
Variable_name: ssl_crlpath
Value:
*************************** 9. row ***************************
Variable_name: ssl_key
Value: /opt/bitnami/mariadb/certs/server-key.pem
Found this in the MariaDB startup log:
2022-10-18 23:32:19 0 [Warning] Failed to setup SSL
2022-10-18 23:32:19 0 [Warning] SSL error: SSL_CTX_set_default_verify_paths failed
2022-10-18 23:32:19 0 [Warning] SSL error: error:02001002:system library:fopen:No such file or directory
2022-10-18 23:32:19 0 [Warning] SSL error: error:2006D080:BIO routines:BIO_new_file:no such file
2022-10-18 23:32:19 0 [Warning] SSL error: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib
I took a look at the have_ssl = disabled thing, and found this.
bitnami#ip-172-26-11-184:~/stack/mariadb/conf/certs$ ls -lah
total 40K
drwxr-xr-x 2 bitnami root 4.0K Oct 9 04:17 .
drwxrwxr-x 4 root root 4.0K Oct 18 22:10 ..
-rw-r--r-- 1 bitnami root 1.7K Oct 9 04:16 ca-key.pem
-rw-r--r-- 1 bitnami root 1.4K Oct 9 04:17 ca.pem
-rw-r--r-- 1 bitnami root 1.3K Oct 9 04:17 client-cert.pem
-rw------- 1 bitnami root 1.7K Oct 9 04:17 client-key.pem
-rw-r--r-- 1 bitnami root 1.1K Oct 9 04:17 client-req.pem
-rw-r--r-- 1 bitnami root 1.3K Oct 9 04:17 server-cert.pem
-rw------- 1 bitnami root 1.7K Oct 9 04:17 server-key.pem
-rw-r--r-- 1 bitnami root 1.1K Oct 9 04:17 server-req.pem
bitnami#ip-172-26-11-184:~/stack/mariadb/conf$ ls -lah
total 24K
drwxrwxr-x 4 root root 4.0K Oct 18 22:10 .
drwxr-xr-x 12 root root 4.0K Apr 14 2022 ..
drwxrwxr-x 3 root root 4.0K Sep 5 11:52 bitnami
drwxr-xr-x 2 bitnami root 4.0K Oct 9 04:17 certs
-rw-rw-r-- 1 bitnami root 1.1K Oct 18 22:10 my.cnf
-rw-r--r-- 1 root root 1002 Oct 9 04:16 run.sh
Amongst other things in my my.cnf:
[mysqld]
skip_name_resolve
explicit_defaults_for_timestamp
basedir=/opt/bitnami/mariadb
port=3306
tmpdir=/opt/bitnami/mariadb/tmp
socket=/opt/bitnami/mariadb/tmp/mysql.sock
pid_file=/opt/bitnami/mariadb/tmp/mysqld.pid
max_allowed_packet=16M
bind_address=0.0.0.0
log_error=/opt/bitnami/mariadb/logs/mysqld.log
slow_query_log=0
slow_query_log_file=/opt/bitnami/mariadb/logs/mysqld.log
long_query_time=10.0
character_set_server=utf8
collation_server=utf8_general_ci
plugin_dir=/opt/bitnami/mariadb/lib/plugin
ssl_ca=/opt/bitnami/mariadb/certs/ca.pem
ssl_cert=/opt/bitnami/mariadb/certs/server-cert.pem
ssl_key=/opt/bitnami/mariadb/certs/server-key.pem
require_secure_transport=ON
Does anyone have any ideas of what to try next and why it's not working?
I got to the bottom of it.
Lessons learnt:
If
MariaDB [bitnami_wordpress]> SHOW GLOBAL VARIABLES LIKE '%ssl%' \G
shows
Variable_name: have_ssl
Value: DISABLED
Then your server side SSL is not enabled.
Check the MySQL log on reload/restart
[Warning] SSL error: error:02001002:system library:fopen:No such file or directory 2022-10-18 23:32:19 0
This kind of thing is a hint - in my case that I'd listed the paths wrong in the config file
The certificates that are needed on the client side are:
The Certificate Authority (ca.pem)
Client Cert
Client Key
In my case, I had the server cert, rather than the CA certificate.
It may be worth trying to connect with the certificates from a commandline client, but whatever "--ssl-verify-server-cert " does, it isn't what App Script does when it tries to connect.
Thanks #danblack for the pointers and encouragement.
I´m trying to implement the TLS server feature available with pgBackRest to use a secure connection between the DB server and the repo server, replacing the previous SSH passwordless setup (that was working fine).
After following the online documentation, I´m having the following error when issuing the stanza-create command :
pgbackrest#pgb-repo$ pgbackrest --stanza=training --log-level-console=info stanza-create
2022-06-13 12:56:55.677 P00 INFO: stanza-create command begin 2.39: --buffer-size=16MB --exec-id=8994-62e5ecac --log-level-console=info --log-level-file=info --pg1-host=pg1-primary --pg1-host-ca-file=/etc/pgbackrest/cert/ca.crt --pg1-host-cert-file=/etc/pgbackrest/cert/pg1-primary.crt --pg1-host-key-file=/etc/pgbackrest/cert/pg1-primary.key --pg1-host-type=tls --pg1-host-user=postgres --pg1-path=/data/postgres/13/pg_data --repo1-path=/backup/pgbackrest --stanza=training
WARN: unable to check pg1: [HostConnectError] unable to connect to 'pg1-primary:8432': [113] No route to host
ERROR: [056]: unable to find primary cluster - cannot proceed
HINT: are all available clusters in recovery?
2022-06-13 12:58:55.835 P00 INFO: stanza-create command end: aborted with exception [056]
The PostgreSQL server is up and running on the the DB host:
[postgres#pg1-primary ~]$ psql -c "SELECT pg_is_in_recovery();"
pg_is_in_recovery
-------------------
f
(1 row)
Question
Why am I having this [113] No route to host error ?
Configuration for each server :
pg1-primary
[postgres#pg1-primary ~]$ cat /etc/pgbackrest/pgbackrest.conf
[global]
repo1-path=/backup/pgbackrest
repo1-host-ca-file=/etc/pgbackrest/cert/ca.crt
repo1-host-cert-file=/etc/pgbackrest/cert/pgb-repo.crt
repo1-host-key-file=/etc/pgbackrest/cert/pgb-repo.key
repo1-host-type=tls
tls-server-address=*
tls-server-auth=pgb-repo=training
tls-server-ca-file=/etc/pgbackrest/cert/ca.crt
tls-server-cert-file=/etc/pgbackrest/cert/pg1-primary.crt
tls-server-key-file=/etc/pgbackrest/cert/pg1-primary.key
[postgres#pg1-primary ~]$ cat /etc/pgbackrest/conf.d/training.conf
[training]
pg1-path=/data/postgres/13/pg_data
pg1-socket-path=/tmp
repo1-host=pgb-repo
repo1-host-user=pgbackrest
[postgres#pg1-primary ~]$ ll /etc/pgbackrest/cert/
total 20
-rw-------. 1 postgres postgres 1090 Jun 13 12:12 ca.crt
-rw-------. 1 postgres postgres 977 Jun 13 12:12 pg1-primary.crt
-rw-------. 1 postgres postgres 1708 Jun 13 12:12 pg1-primary.key
-rw-------. 1 postgres postgres 977 Jun 13 12:23 pgb-repo.crt
-rw-------. 1 postgres postgres 1704 Jun 13 12:23 pgb-repo.key
pgb-repo
pgbackrest#pgb-repo$ cat /etc/pgbackrest/pgbackrest.conf
[global]
repo1-path=/backup/pgbackrest
tls-server-address=*
tls-server-auth=pg1-primary=training
tls-server-ca-file=/etc/pgbackrest/cert/ca.crt
tls-server-cert-file=/etc/pgbackrest/cert/pgb-repo.crt
tls-server-key-file=/etc/pgbackrest/cert/pgb-repo.key
pgbackrest#pgb-repo$ cat /etc/pgbackrest/conf.d/training.conf
[training]
pg1-host=pg1-primary
pg1-host-user=postgres
pg1-path=/data/postgres/13/pg_data
pg1-host-ca-file=/etc/pgbackrest/cert/ca.crt
pg1-host-cert-file=/etc/pgbackrest/cert/pg1-primary.crt
pg1-host-key-file=/etc/pgbackrest/cert/pg1-primary.key
pg1-host-type=tls
pgbackrest#pgb-repo$ ll /etc/pgbackrest/cert/
total 20
-rw-------. 1 pgbackrest pgbackrest 1090 Jun 13 12:27 ca.crt
-rw-------. 1 pgbackrest pgbackrest 977 Jun 13 12:27 pg1-primary.crt
-rw-------. 1 pgbackrest pgbackrest 1708 Jun 13 12:27 pg1-primary.key
-rw-------. 1 pgbackrest pgbackrest 977 Jun 13 12:27 pgb-repo.crt
-rw-------. 1 pgbackrest pgbackrest 1704 Jun 13 12:27 pgb-repo.key
The servers are reachable from one another:
[postgres#pg1-primary ~]$ ping pgb-repo
PING pgb-repo.xxxx.com (XXX.XX.XXX.117) 56(84) bytes of data.
64 bytes from pgb-repo.xxxx.com (XXX.XX.XXX.117): icmp_seq=1 ttl=64 time=0.365 ms
64 bytes from pgb-repo.xxxx.com (XXX.XX.XXX.117): icmp_seq=2 ttl=64 time=0.421 ms
pgbackrest#pgb-repo$ ping pg1-primary
PING pg1-primary.xxxx.com (XXX.XX.XXX.116) 56(84) bytes of data.
64 bytes from pg1-primary.xxxx.com (XXX.XX.XXX.116): icmp_seq=1 ttl=64 time=0.325 ms
64 bytes from pg1-primary.xxxx.com (XXX.XX.XXX.116): icmp_seq=2 ttl=64 time=0.298 ms
So actually the issue had to do with the firewall preventing access to the default TLS port (8432) used by pgBackRest.
[root#pgb-server ~]# firewall-cmd --zone=public --add-port=8432/tcp --permanent
[root#pgb-server ~]# firewall-cmd --reload
Once the port was accessible through the firewall I could issue a telnet command successfully (for testing access) - and of course run my pgBackRest commands too.
[pgbackrest#pgb-server]$ telnet pg1-server 8432
Trying 172.XX.XXX.XXX...
Connected to pg1-server.
Escape character is '^]'.
running fedora 27 here. I'm attempting to run slapd from a fresh openldap install. When I try and run with systemctl start openldap, the daemon fails to start. journalctl gives the following output:
Jun 19 00:30:25 slapd[1325]: #(#) $OpenLDAP: slapd 2.4.45 (Dec 6 2017 14:25:36) $
mockbuild#buildhw-08.phx2.fedoraproject.org:/builddir/build/BUILD/openldap-2.4.45/openldap-2.4.45/servers/slapd
Jun 19 00:30:25 slapd[1326]: mdb_db_open: database "dc=my-domain,dc=com" cannot be opened: Permission denied (13). Restore from backup!
Jun 19 00:30:25 slapd[1326]: backend_startup_one (type=mdb, suffix="dc=my-domain,dc=com"): bi_db_open failed! (13)
Jun 19 00:30:25 slapd[1326]: slapd stopped.
Jun 19 00:30:25 audit[1326]: AVC avc: denied { map } for pid=1326 comm="slapd" path="/var/lib/ldap/lock.mdb" dev="xvda1" ino=1716389 scontext=system_u:system_r:slapd_t:s0 tcontext=system_u:object_r:slapd_db_t:s0 tclass=file permissive=0
However, if I run the daemon directly with /usr/sbin/slapd -u ldap -d -1 -h "ldap:/// ldaps:/// ldapi:///", the daemon starts with no issue.
My systemctl script is below:
[Unit]
Description=OpenLDAP Server Daemon
After=syslog.target network-online.target
Documentation=man:slapd
Documentation=man:slapd-config
Documentation=man:slapd-hdb
Documentation=man:slapd-mdb
Documentation=file:///usr/share/doc/openldap-servers/guide.html
[Service]
Type=forking
ExecStartPre=/usr/libexec/openldap/check-config.sh
ExecStart=/usr/sbin/slapd -u ldap -h "ldap:/// ldaps:/// ldapi:///"
[Install]
WantedBy=multi-user.target
Alias=openldap.service
I've checked permissions on the ldap config directory and db directory and they seem correct for the ldap user:
[root#localhost operations]# ll /etc/openldap/slapd.d/cn\=config
total 24
drwxr-x---. 2 ldap ldap 4096 Jun 15 23:00 'cn=schema'
-rw-------. 1 ldap ldap 378 Jun 15 23:00 'cn=schema.ldif'
-rw-------. 1 ldap ldap 513 Jun 15 23:00 'olcDatabase={0}config.ldif'
-rw-------. 1 ldap ldap 412 Jun 15 23:00 'olcDatabase={-1}frontend.ldif'
-rw-------. 1 ldap ldap 562 Jun 15 23:00 'olcDatabase={1}monitor.ldif'
-rw-------. 1 ldap ldap 609 Jun 15 23:00 'olcDatabase={2}mdb.ldif'
[root#localhost operations]# ll /var/lib/| grep ldap
drwx------. 2 ldap ldap 4096 Jun 19 00:30 ldap
[root#localhost operations]# ll /var/lib/ldap/
total 0
-rw-------. 1 ldap ldap 8192 Jun 19 00:30 lock.mdb
Any advice would be much appreciated.
It seems you're using back-mdb. Good.
Does your DB directory /var/lib/ldap/ really contain only file lock.mdb?
There should also be a bigger file called data.mdb with the actual data.
Fix as jayant say.
cat upload.sh
/home/Dropbox-Uploader/dropbox_uploader.sh upload -f /home/Dropbox-Uploader/.dropbox_uploader /home/material/* /
date >> /home/upload.log
All files in directory material can be uploaded into my dropbox with bash upload.sh.
I want to write a autorun service at shutdown to upload files into dropbox.
vim /etc/systemd/system/upload.service
[Unit]
Description=upload files into dropbox
Before=network.target shutdown.target reboot.target
[Service]
ExecStart=/bin/true
ExecStop=/bin/bash /home/upload.sh
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
Enable it with:
sudo systemctl enable upload.service
To reboot it.
journalctl -u upload
-- Logs begin at Thu 2018-01-18 22:38:54 EST, end at Tue 2018-04-10 06:55:43 EDT. --
Apr 10 06:48:27 localhost systemd[1]: Started upload files into dropbox.
Apr 10 06:48:27 localhost systemd[1]: Starting upload files into dropbox...
Apr 10 06:48:27 localhost bash[111]: which: no shasum in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin)
Apr 10 06:48:27 localhost bash[111]: > Uploading "/home/material/test.txt" to "/test.txt"...
Apr 10 06:48:27 localhost bash[111]: Error: Couldn't resolve host.
ln -s /usr/bin/sha1sum /usr/bin/shasum according to google's result.
Reboot the second time.
journalctl -u dropbox
Apr 10 06:55:04 localhost systemd[1]: Started upload files into dropbox.
Apr 10 06:55:04 localhost systemd[1]: Starting upload files into dropbox...
Apr 10 06:55:04 localhost bash[113]: shasum: invalid option -- 'a'
Apr 10 06:55:04 localhost bash[113]: Try 'shasum --help' for more information.
Apr 10 06:55:04 localhost bash[113]: shasum: invalid option -- 'a'
Apr 10 06:55:04 localhost bash[113]: Try 'shasum --help' for more information.
Apr 10 06:55:04 localhost bash[113]: > Uploading "/home/material/test.txt" to "/test.txt"...
Apr 10 06:55:04 localhost bash[113]: Error: Couldn't resolve host.
Do as Raushan say,new issue arised,
Uploading by 4 chunks *** FAILED dropbox
For the problem Uploading by 4 chunks *** FAILED dropbox ,some material say that if files exceeding 150 mb should be uploaded in chunks.
split -b 10m /home/upload.tar.gz /home/material/dropbox
ls /home/material
dropboxaa dropboxac dropboxae dropboxag ......
Both of them is less than 10m.
journalctl -u upload
Apr 19 01:45:26 localhost systemd[1]: Started upload files into dropbox.
Apr 19 01:45:26 localhost systemd[1]: Starting upload files into dropbox...
Apr 19 01:45:27 localhost bash[401]: > Uploading "/home/material/dropboxaa" to "/dropboxaa"... FAILED
Apr 19 01:45:27 localhost bash[401]: An error occurred requesting /upload
Apr 19 01:45:28 localhost bash[401]: > Uploading "/home/material/dropboxab" to "/dropboxab"... FAILED
Apr 19 01:45:40 localhost bash[401]: Some error occured. Please check the log.
Apr 19 01:45:40 localhost systemd[1]: upload.service: main process exited, code=exited, status=1/FAILURE
Apr 19 01:45:40 localhost systemd[1]: Unit upload.service entered failed state.
Apr 19 01:45:40 localhost systemd[1]: upload.service failed.
Why > Uploading "/home/material/dropboxaa" to "/dropboxaa"... FAILED?
It is not possible that the second instruction of your script executes without executing the first one. Try redirecting the error output of the dropbox_uploader.sh to see what is failing.
Assuming you are using dropbox-uploader, try specifying the exact location of the configuration file. See Running as cron job section in their README.md
/home/Dropbox-Uploader/dropbox_uploader.sh -f /path/to/.dropbox_uploader upload /home/material/* /
For the Couldn't resolve host problem :
Unit configuration should have dependency like
After=network.target instead of Before=network.target as the default shutdown order is inverse of startup
[Unit]
Description=upload files into dropbox
Before=shutdown.target reboot.target
After=network.target
[Service]
ExecStart=/bin/true
ExecStop=/bin/bash /home/upload.sh
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
Refer: https://serverfault.com/a/785355
For the shasum problem :
I am not sure about your OS distro, I am using Fedora 25.
In my case shasum binary is from perl-Digest-SHA package which can be installed by command yum install perl-Digest-SHA on RedHat based linux distro
Refer: https://superuser.com/a/1180163
I'm new to writing permissions in Apache. This is a shared sever of which I have one account on it.
I was having an issue with FileZilla not being able to write to my var/www directory and in an attempt to change its permissions I think I have made it worse.
Here are my current settings
$ ls -l
total 40
drwxr-xr-x 2 root root 4096 Feb 5 2013 backups
drwxr-xr-x 7 root root 4096 Jul 30 2013 cache
drwxr-xr-x 26 root root 4096 Jul 30 2013 lib
drwxrwsr-x 2 root staff 4096 Apr 15 2008 local
lrwxrwxrwx 1 root root 9 Feb 5 2013 lock -> /run/lock
drwxr-xr-x 7 root root 4096 Jul 30 2013 log
drwxrwsr-x 2 root mail 4096 Feb 5 2013 mail
drwxr-xr-x 2 root root 4096 Feb 5 2013 opt
lrwxrwxrwx 1 root root 4 Feb 5 2013 run -> /run
drwxr-xr-x 4 root root 4096 Feb 5 2013 spool
drwxrwxrwt 2 root root 4096 Feb 5 2013 tmp
drwxrwx--- 2 root root 4096 Jul 30 2013 www
Can anyone tell me what are the correct permissions to have on the www folder, and even better how to obtain them?
I think it should be
drwxrwxr-x 2 root root 4096 Jul 30 2013 www
Thanks
There is no such thing as "correct permissions".
There's the permissions setup which was used as default in your installation.
There's the right permissions to use for YOUR security model
You appear to be using a security model which requires non-standard permissions, And you've not once mentioned 'users' or 'groups' let alone what your security model is.
As root, you should chown /var/www to whoever should 'own' the directory (hint: it's neither root nor the apache uid) then set the group ownership appropriately (we can't tell from the information you've provided what that is - but again it's neither root nor the apache uid) then chmod o_rx the directory.
Then please go learn a bit about Linux/Unix admin - try googling for "the rute"