Install ownCloud 8.x on CentOS 7
-
Note: I do not have a trusted SSL certificate available to go on this server so I went with a self signed until letsencrypt.org gets into beta.
To enable SSL on your ownCloud server is very simple.
Install the apache module
yum -y install mod_ssl
Create a directory for the certificate to reside
mkdir /etc/httpd/ssl
Create a self signed certificate
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/httpd/ssl/owncloud.key -out /etc/httpd/ssl/owncloud.crt
Fill out the certificate information. Make sure the Common Name matches the DNS name you will be using.
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:SomeState
Locality Name (eg, city) [Default City]:SomeCity
Organization Name (eg, company) [Default Company Ltd]:SomeCompany
Organizational Unit Name (eg, section) []:SomeDept
Common Name (eg, your name or your server's hostname) []:owncloud.domain.com
Email Address []:[email protected]
Edit the Apache config file for SSL (I like nano)
nano /etc/httpd/conf.d/ssl.conf
Find the DocumentRoot line and uncoment it.
DocumentRoot "/var/www/html"
Find the SSLCertificateFile and SSLCertificateKeyFile lines and change them to point to the location we created the SSL key and certificate
SSLCertificateFile /etc/httpd/ssl/owncloud.crt
SSLCertificateKeyFile /etc/httpd/ssl/owncloud.key
Save file and exit nano
Edit the ownCloud config
nano /var/www/html/owncloud/config/config.php
Add the DNS name to the trusted domains array
1 => 'owncloud.domain.com',
updated the overwrite.cli.url to use the DNS name
'overwrite.cli.url' => 'https://owncloud.domain.com/owncloud',
Save the file and exit nano
Update the firewall to allow https
firewall-cmd --zone=public --add-port=https/tcp --permanent
firewall-cmd --reload
Restart apache
apachectl restart
You can now access your ownCloud server via HTTPS. You will receive the typical self signed warning from any modern browser, but the service will work and be encrypted.
-
Now that everything is working you need to create your DNS entries internally and externally and port forward 443 in your router to point to your ownCloud server.
The only thing left is to get SELinux to play nice. The instructions on the ownCloud document site do not work. SO make sure to
setenforce 0
after a reboot until we work that out. -
@jospoortvliet any feedback on the SELinux issues?
If I set SELinux back to enforcing, I get an error that the config directory cannot be wrote to.
I ran these commands as listed:
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/owncloud/data'
restorecon '/var/www/html/owncloud/data'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/owncloud/config'
restorecon '/var/www/html/owncloud/config'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/owncloud/apps'
restorecon '/var/www/html/owncloud/apps'
But unless i use
setenforce permissive
it does not work. -
For free SSL, I've been using StartCom (http://www.startssl.com/?app=32). Works great in Desktop OSes... Still not trusted on mobile devices yet.
-
@dafyre said:
For free SSL, I've been using StartCom (http://www.startssl.com/?app=32). Works great in Desktop OSes... Still not trusted on mobile devices yet.
You cannot do subdomains with them I believe? I looked into them once before and there was a problem with it, but I do not recall what.
-
@dafyre said:
For free SSL, I've been using StartCom (http://www.startssl.com/?app=32). Works great in Desktop OSes... Still not trusted on mobile devices yet.
I use them for my own OwnCloud instance. Works amazing. All of my Android phones recognized them as well.
-
@JaredBusch said:
@jospoortvliet any feedback on the SELinux issues?
If I set SELinux back to enforcing, I get an error that the config directory cannot be wrote to.
I ran these commands as listed:
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/owncloud/data'
restorecon '/var/www/html/owncloud/data'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/owncloud/config'
restorecon '/var/www/html/owncloud/config'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/owncloud/apps'
restorecon '/var/www/html/owncloud/apps'
But unless i use
setenforce permissive
it does not work.What if you just do
chcon -R -t httpd_sys_rw_content_t /var/www/html/owncloud/config
You can also find another folder with the same label type and try it.
chcon -R --reference=<known good folder> /var/www/html/owncloud/config
-
@johnhooks said:
What if you just do
chcon -R -t httpd_sys_rw_content_t /var/www/html/owncloud/config
That worked. So now to understand why, because I admit to not knowing a lot about SELinux.
Did not the semanage command set the security context as expected? Would this imply that potentially, the other commands also did not do what was expected fo rthe /data and /apps folders?
-
This post is deleted! -
@JaredBusch said:
@johnhooks said:
What if you just do
chcon -R -t httpd_sys_rw_content_t /var/www/html/owncloud/config
That worked. So now to understand why, because I admit to not knowing a lot about SELinux.
Did not the semanage command set the security context as expected? Would this imply that potentially, the other commands also did not do what was expected fo rthe /data and /apps folders?
Was there data in the folder before the context change? If so they didn't add the -R for the restorecon command. Chcon doesn't create a permanent change, so you should be able to type:
restorecon -R -v /var/www/html/owncloud/config
And it will put everything back the way it was. Then if you type
ls -lZ /var/www/html/owncloud/config
it will list the context for all of the files in the config folder. If they are back to the original context but the parent folder isn't, that's what happened. If not something else happened.
-
And after a little more looking around, even if you use the -R on restorecon it still wouldn't work. That's because the semanage command they have listed doesn't change the files inside. It should look like this:
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/owncloud/config(/.*)?"
Then it will include everything inside the folder.
So it would seem you would have to run that for each folder again.
If you pass -v with restorecon it will show you all the files it changed so you can make sure it did it correctly.
-
@johnhooks said:
And after a little more looking around, even if you use the -R on restorecon it still wouldn't work. That's because the semanage command they have listed doesn't change the files inside. It should look like this:
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/owncloud/config(/.*)?"
Then it will include everything inside the folder.
So it would seem you would have to run that for each folder again.
If you pass -v with restorecon it will show you all the files it changed so you can make sure it did it correctly.
I have not had time to circle back to this, but I will. thanks.
-
More stupid issues with ownCloud. The system I setup while creating these instructions is wokring normally for the users. But here is more evidence that ownCloud just does not quite get things right...
This is what greats me when logged in to the settings tab as an administrator.
-
I set up an ownCloud system one time, but I did find that Seafile seems to sync much faster. They've also come a long way with their web interface.
-
ownCloud is REALLY making it hard to love them. My personal system setup last year has issues, but it was hacked together in CentOS 7 before the EPEL was even out for 7. I expected problems.
But this new install is now up but without disc space because I assumed (wrongly) that ownCloud would put their default data directory in whatever their install kit makes the largest ext3 partition. Nope..
The default location is /var/www/html/owncloud/data. A 50GB partition from a 300 GB vdisk.[root@owncloud ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/centos-root 50G 18G 33G 36% / devtmpfs 232M 0 232M 0% /dev tmpfs 241M 0 241M 0% /dev/shm tmpfs 241M 4.3M 236M 2% /run tmpfs 241M 0 241M 0% /sys/fs/cgroup /dev/sda2 497M 129M 368M 26% /boot /dev/sda1 200M 9.8M 191M 5% /boot/efi /dev/mapper/centos-home 249G 33M 249G 1% /home
-
I moved everything easily enough, but my point is that a default install should handle this.
To move everything shut down the webserver
systemctl stop httpd
Create the directory structure up to just before the /data folder. IN my case I wanted to simply move it to /home/owncloud/data.
mkdir /home/owncloud
Now move the data folder.
mv /var/www/html/owncloud/data /home/owncloud/data
Change ownership to apache
chown -R apache:apache /home/owncloud/data
Update SELinux
semanage fcontext -a -t httpd_sys_rw_content_t "/home/owncloud/data(/.*)?"
Edit the ownCloud config file to reflect the new location
sed -i -e 's/\/var\/www\/html\/owncloud\/data/\/home\/owncloud\/data/' /var/www/html/owncloud/config/config.php
Restart the webserver
systemctl start httpd
-
Now it all looks like this.
[root@owncloud ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/centos-root 50G 1.4G 49G 3% / devtmpfs 232M 0 232M 0% /dev tmpfs 241M 0 241M 0% /dev/shm tmpfs 241M 4.3M 236M 2% /run tmpfs 241M 0 241M 0% /sys/fs/cgroup /dev/sda2 497M 129M 368M 26% /boot /dev/sda1 200M 9.8M 191M 5% /boot/efi /dev/mapper/centos-home 249G 34G 215G 14% /home
-
@JaredBusch said:
@dafyre said:
For free SSL, I've been using StartCom (http://www.startssl.com/?app=32). Works great in Desktop OSes... Still not trusted on mobile devices yet.
You cannot do subdomains with them I believe? I looked into them once before and there was a problem with it, but I do not recall what.
I've not had any problems with the subdomains. They just make you verify that you own the top level domain.... It works great so far.
-
@dafyre said:
@JaredBusch said:
@dafyre said:
For free SSL, I've been using StartCom (http://www.startssl.com/?app=32). Works great in Desktop OSes... Still not trusted on mobile devices yet.
You cannot do subdomains with them I believe? I looked into them once before and there was a problem with it, but I do not recall what.
I've not had any problems with the subdomains. They just make you verify that you own the top level domain.... It works great so far.
I never tried. I stopped when I seen this. See, I apparently was not paying attention to detail and assumed.. My cert is now created, thanks!
-
With ownCloud now working, you should secure logins with fail2ban
Install fail2ban
yum -y install fail2ban
create the initial jail file
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
add ownlcoud to the jail.local
nano /etc/fail2ban/jail.local
paste this data in at the bottom
[owncloud] enabled = true filter = owncloud port = http,https # 'This is the data path we set earlier. Change if yours is different.' logpath = /home/owncloud/data/owncloud.log
Create the owncloud filter file
nano /etc/fail2ban/filter.d/owncloud.conf
Paste in the following ONLY FOR ownCloud 8.2
Other regex patterns can be found in this thread[Definition] failregex={"reqId":".*","remoteAddr":".*","app":"core","message":"Login failed: '.*' \(Remote IP: '<HOST>'\)","level":2,"time":".*"} ignoreregex =
Start fail2ban and enable it to start on boot
systemctl start fail2ban
systemctl enable fail2ban
Note: This is only securing ownCloud. Consult the jail.local to enable other protections you may want.