De schrijver van ‘Little Fuzzy’ is in 1964 overleden, meer dan 50 jaar geleden dus, waardoor het auteursrecht op het boek verlopen is. Ik kon en mocht het daarom gratis downloaden. Little Fuzzy bespreekt een aantal interessante kwesties, zoals hoe je intelligentie kan definiëren. Verder is het redelijk zoetsappig, maar persoonlijk heb ik daar weinig bezwaar tegen.
Als je dieper gaat graven, kan je vast nog heel veel vinden over Zarathustra (de naam van de planeet waar het verhaal zich afspeelt) en de manier van handelen van de karakters in het verhaal.
Alles bij elkaar vond ik het gewoon een leuk verhaal om te lezen. Weet je een keer niks te lezen dan kan je Little Fuzzy voor nop downloaden. Niks te verliezen dus.
# cd /var/www/html/phpvirtualbox/
# cp config.php-example config.php
In /var/www/html/phpvirtualbox/config.php change:
var $username = 'vbox';
var $password = 'P@55w0rd';
Use the password you gave the vbox user earlier on.
Open your browser and point it to your server’s address followed by /phpvirtualbox, for example http://myserver/phpvirtualbox. Default username and password are both admin.
To view the VM, select it and on the right side click the Console button. If all is well you will be able to select your desired screen resolution and connect to the VM.
The part that provides this is actually an RDP client embedded in the VirtualBox Extention Pack. If it doesn’t work make sure you have the latest Extension Pack installed.
It is also possible (and faster) to view the VM from a locally installed RDP client.
If you’re on a Windows system just run
or type remote desktop in the Start Menu box.
In the Remote Desktop Connection window type the IP address of the server hosting VirtualBox (not the address of your virtual machine) followed by the port number.
The port number defaults to 9000 but you can set it from the virtual machine’s properties in VirtualBox: Display > Remote Display.
A port or port range is accepted.
If unsure just check what the built-in console wants to connect to:
Remote Desktop will then show your virtual machine.
Alternatively select the VM in phpVirtualBox and from the Details window, under Display, click on the port number. This will fire up your RDP client.
There are terminal services clients for just about any operating system.
– phpVirtualBox’s default username and password are both admin.
– VirtualBox’s default interface and phpVirtualBox even more so do not show all options. If you need to perform an operation on a VM that requires options not shown in the GUIs use the command line interface: VBoxManage. Its documentation is excellent and it allows you to access all available options.
– If you use VBoxManage remember to do it under the account of your dedicated VM user (c.q. vbox). If you use root or any other account not in /var/www/phpvirtualbox/config.php the operations will not be reflected in the web interface.
– phpVirtualBox major and minor versions always reflect VirtualBox versions.
– A very cool feature is remote usb. You can pass your usb device through to the VM via the remote display. Haven’t tested it yet but I will. Read all about it here!
– If you’re planning on running PfSense like I did or just *BSD check out this post on fixing a high CPU load.
My notes on installing phpSysInfo on Debian Jessie, just so I won’t forget.
Install the necessary software:
# aptitude install apache2 php5 phpsysinfo
Create a configuration amendment for Apache. Create the following file in /etc/apache2/conf-available/phpsysinfo.conf:
Alias /phpsysinfo /usr/share/phpsysinfo
Deny from all
Allow from localhost
# Change next line to your own subnet or IP
Allow from 192.168.1.
Allow from all
De term ‘Halo:’ had ik af en toe voorbij zien komen op Tweakers.net en daarom heb ik er weinig aandacht aan besteed: voor spelletjes moet je de tijd nemen. Ik was daarom redelijk skeptisch toen ik begon aan Greg Bears Halo: Cryptum. Ik wist niet zeker of dit boek met het spel te maken had. Achteraf bleek van wel en had ik dat geweten dan had ik er nog eens over nagedacht.
Greg Bear is echter een steengoeie schrijver en zelfs zijn technothrillers vind ik geweldig. Daar kan je je niet echt een buil aan vallen, dacht ik. Halo komt echter uit de pr-koker van Microsoft en we weten allemaal wat daaruit komt…
Het Halo-universum zit interessant en goed doordacht in elkaar. Het verhaal is aardig. De karakters zijn naar Bear-maatstaven matig maar relatief aan gemiddelde schrijvers redelijk. De ingrediënten zijn er allemaal maar op de een of andere manier wordt het niet één geheel. Het leek of het voor iemand anders was geschreven en achteraf werd ook duidelijk waarom: het is gewoon een verhaal dat bedoeld is als achtergrond bij een schietspelletje. Als je graag Halo speelt dan zal het vast een geweldig boek zijn.
De scifi die we van Bear gewend zijn biedt vaak een nieuwe kijk op de werkelijkheid en inzichten in de mens. Halo biedt voornamelijk inzichten in het fictieve Halo-universum. Technisch niks op aan te merken.
OwnCloud does a fine job listing the steps for creating backups and updating an ownCloud server. Read all about it here. I’m not going to copy ownCloud’s information here. I’ll give some sample scripts you can use targeted at the specific lab setup we created in the previous parts of this series.
Backup up ownCloud
As per ownCloud’s suggestions below script backs up the config folder, the data folder and the database. In addition it lists all installed packages; this list can serve as a base to quickly reinstall them should you need to reinstall your server.
This script backs up to a Windows server. It assumes you have installed smbclient and /root/.smbcreds contains the Windows server share’s credentials in this format:
The file should only be readable by root:
# chmod 600 /root/.smbcreds
The script creates daily folders containing full backups. I suggest you keep a bunch of recent ones and some older ones, or back up the config and data separately in order to not completely fill up your drives in a week.
The backups are stored in the share \\server01\backups in a folder called “ownCloud daily backups” to demonstrate how to handle paths with spaces.
Create a file called /root/backup.sh:
# Create backupdir
# Write list of installed packages to backupdir
dpkg --get-selections | grep -v deinstall > ./$NOW/InstalledPackages.txt
# Copy software config to backup dir
cp -R /etc/ ./$NOW
# Copy ownCloud install and config to backup dir
cp -R /var/www/owncloud ./$NOW
# Copy ownCloud data to backup dir
cp -R /var/ownclouddata ./$NOW
# Export Mysql database and copy to backup dir
mysqldump -uroot --password=Y0urSqLp4ssw0rd --events --all-databases > ./$NOW/mysqlbackup.sql
# Copy backupdir to tarball
tar -cvpzf backup-$NOW.tar.gz ./$NOW
# Copy tarball to backup server
smbclient //server01/backups -l 192.168.1.2 -A /root/.smbcreds -c "cd \"ownCloud daily backups\"; put backup-$NOW.tar.gz backup-$NOW.tar.gz"
# Remove backupdir and tarball
rm -R /root/$NOW
Make the script executable:
# chmod +x /root/backup.sh
Configure the script to run every night using cron:
# crontab -e
Add this line:
59 0 * * * bash /root/backup.sh
Check your backups regularly.
Of course if you’re running ownCloud on a VM you could just create exports and save those on your server.
To restore your backup to a fresh installation first completely setup the server:
Setup the correct repositories
Reinstall all software with the selections list from your backup:
The only thing I want to add is you may want to create a snapshot of your server before upgrading.
I compliment ownCloud on their ongoing professional and technical growth. And I know it’s not a favourite activity of a lot of people but ownCloud really improved their documentation in the last couple of years. I hope they will continue on this path.
OwnCloud sometimes needs to send out mail, for example when a user wants to share a link via e-mail or needs to use the password recovery function. OwnCloud offers three methods for mail: SMTP, sendmail and PHP. I’ll describe two of them.
Gmail via SMTP
In case your ISP doesn’t allow outgoing traffic on port 25 you can use your Gmail account to send out mail. It’s an easy workaround and the drawback is the mail have your Gmail address as sender. For private use that’s ok, or even for a small company.
The setup is pretty straightforward.
Send mode: smtp
From address: can be anything
Authentication method: Plain [x] Authentication required
Server address: smtp.gmail.com:587
Credentials: email@example.com P@55w0rd -> Store credentials
Click Send email to test your settings and if the ‘Email sent’ box turns green you’re set.
Email via PHP
If you’re in a larger company or you don’t want to use a Gmail account set Send mode to php. Fill out a dedicated sender address and click the Send email button. The address doesn’t have to exist but it’s best if it does.
Document support is a fun feature in ownCloud but not much more than that. It’s not an Office 365 or Google Docs replacement. I use it for private purposes or to open the occasional Word document but that’s about it. Try it out if your server can handle a LibreOffice installation.
OwnCloud supports ODF documents natively. For MS Word support you need to install LibreOffice or one of the OpenOffices:
# aptitude install libreoffice
In the ownCloud web interface go to Admin > Apps…
At Productivity > Documents click Enable
On the Admin page at Documents select Local and click ‘Apply and test’. If a green button says Saved everything is in order.
This part is about basic security. OwnCloud lists a number of security options on their site. We’ll be going over their suggestions and add one extra while we’re at it. Everything combined should result in a server with a good baseline security.
Set the proper file permissions
OwnCloud provides a script to easily set the proper file permissions on ownCloud installations. Their page also lists all suggested permissions per directory or file so you can set the permissions for modified installations.
Edit ocpath and datapath to your own variables. htuser, htgroup and rootuser are correct if you’re installing on Debian with Apache, which we are. ocpath and datapath contain the correct values for our lab setup.
Make the script executable:
# chmod +x permissions.sh
Run the script:
If no errors occured you’re done!
Enter trusted domains
From the ownCloud site: in /var/www/owncloud/config/config.php change the array of trusted domains. Enter all names and addresses by which you want to be able to access ownCloud. I’ll be using the domainname owncloud.vorkbaard.nl. 192.168.1.3 is ownCloud’s local ip address.
OwnCloud suggest whitelisting ‘localhost’ as well, but 127.0.0.1 is automatically whitelisted and our server has no gui so I think you will survive the one time you need to type localhost’s IP address.
Give PHP read access to /dev/urandom (also: configure open_basedir)
open_basedir is a php.ini directive which specifies which paths PHP is allowed to access through script. If it’s not configured PHP can access any directory allowed by the filesystem. By default PHP in Debian 8 has no configuration for open_basedir so /dev/urandom may be accessed by PHP to acquire entropy.
Since ownCloud has no business being anywhere else on our system but in its own directories, /tmp/ and /dev/urandom let’s tell PHP about this. Open /etc/php5/apache2/php.ini and find the line that reads
Setting up SELinux in Debian is still a bit wonky. We’ll skip it for now. If you have genius suggestions feel free to mention them in the comments 🙂
Place data directory outside of the web root
We did that in the setup so we’re covered!
Disable preview image generation
This is really a choice between functionality and marginally more security. If you’re paranoid about it – or just don’t care about image previews – then disable it. Alternatively sign up for ownCloud’s newsletters and I think you’ll be notified soon enough if a security issue with image generation occurs.
In Apache your have two choices for SSL: either you use a self-signed certificate (appropriately named a snakeoil certificate in Apache) or you pay a certificate vendor a fee for a commercial certificate.
We’ll first do the snakeoil, later on the commercial. The domain I’ll be using is owncloud.vorkbaard.nl. You will need to use your own domain name and pay a DNS provider to tell the rest of the world about it. My DNS provider of choice is Webbed.nl because they provide excellent service for a fair price.
I assume you already have you own domain name and have it pointed at your webserver. If not, just edit your hosts file for now. I’m testing on my Windows AD server so that’s where I’ll edit my hosts file: click Start, type Notepad, rightclick it and choose Run as administrator.
In Notepad open %windir%\system32\drivers\etc\hosts. and add this line:
Save the file and close Notepad. If you can’t save it, open Notepad as administrator.
Ping owncloud.vorkbaard.nl; it should resolve to 192.168.1.3.
If you remembered to add owncloud.vorkbaard.nl to your trusted domains in ownCloud’s config.php you can now connect to ownCloud via http://owncloud.vorkbaard.nl.
On your ownCloud server in /etc/apache2/sites-available open the file default-ssl.conf. Change
Enable the site:
# a2ensite default-ssl
Enable Apache’s SSL module:
# a2enmod ssl
Disable the non-ssl version of the site. Strictly this is optional but there’s no use for it anymore so why keep it?
# a2dissite 000-default.conf
Restart Apache so the SSL module and the changes in enabled/disabled sites take effect:
# service apache2 restart
Now go to https://owncloud.vorkbaard.nl and depending on which browser you are using you’ll get some sort or warning about the missing SSL certificate.
If you’re using Google Chrome like I am click the Advanced link.
Internet Explorer does a similar thing.
Click Proceed to owncloud.vorkbaard.nl (unsafe).
And Bob’s your uncle.
Now, if you are the only user and you’ll only be using ownCloud to sync to your desktop of mobile device you could stop here. Even though there’s no signed and trusted certificate the data that’s sent back and forth would be encrypted just the same.
Just tell your client to trust the certificate anyway.
This is the snakeoil method. It works but it doesn’t look nice and you know the site can be trusted but others don’t.
Error: Your data directory and your files are probably accessible from the internet.
OwnCloud does a strange thing after you enable SSL. On entering the Admin page it verifies whether the data directory (/var/www/owncloud/data by default but we changed it to /var/ownclouddata) is accessible through the internet. It should not be otherwise non-authorized users might type in direct URLs to files and download them. It does this by placing a .htaccess file in the data directory containing supplemental instructions for the webserver. If it can’t find the .htaccess file it will tell you.
It also verifies if it can read from and write to the data directory. It does this by placing a file called htaccesstest.txt in the data directory the moment you open the Admin page. It then tries to remove that file.
The problem is that in between it will do some other stuff for just over two minutes during which the animated ‘loading’ indicator will be shown. The test appears to hang so you might be tempted to reload the page. If you do that when the test has not fully completed the htaccesstest.txt is still there and ownCloud assumes it cannot read-and-write in the data directory and I guess just gives up on the .htaccess file altogether. It will tell you so in the Security & setup warnings section on the Admin page.
After a while though the htaccesstest.txt file disappears. If you:
– then reload the Admin page,
– would have waited for the tests to fully complete, or
– would have manually removed the htaccesstest.txt file
ownCloud will tell you that everything is fine.
I guess this is a bug in ownCloud which will be fixed in time. If you let ownCloud run its tests for two minutes and it tells you everything is in order then next time you can safely ignore the message about the .htaccess file not working and the data directory being in the web server document root. (If however it keeps complaining even after waiting out the full test round you should investigate further.)
Get a commercial certificate
When it comes to commercial certificates there are a lot of options and their prices vary from a small fee to thousands of euros. For private use or a small company what’s important is that things run smoothly and your users don’t get confusing warnings. The cheapest certificates suffice for that. The ones I buy are €8 per year, less if you get certs for more than one year at a time.
I get my certificates at Xolphin.nl because they provide very fast service and are very helpful. I’ll describe the process here but your experience will likely differ if you’re using a different certificate vendor.
Whichever provider you choose the process is always the same:
You generate a Certificate Signing Request (CSR) on your server.
You send the CSR to the certificate vendor.
The vendor verifies your identity. Based on the kind of certificate you are buying this process is less or more elaborate. Basically the more you pay the stricter they are.
The vendor sends you one or more signed certificate files.
You’ll need to enter information that corresponds with that of the domain name owner (DNS registry) or the Chamber of Commerce if applicable. [xx] denotes the standard value.
Country Name (2 letter code) [AU]: your country code. For the Netherlands this would be NL. If in doubt ask Google: https://www.google.nl/search?q=csr+2+letter+country+code+list State or Province Name (full name) [Some-State]: your province Locality Name (eg, city) : your city Organization Name (eg, company) [Internet Widgits Pty Ltd]: your exact company name if applicable, otherwise try your domain name. I tend to use Vorkbaard.nl Organizational Unit Name (eg, section) : ICT dept or whatever you like or is appropriate. Common Name (eg, YOUR name) : your (sub)domainname, e.g. owncloud.vorkbaard.nl. Not your own name. Email Address : firstname.lastname@example.org A challenge password : do not enter anything here An optional company name : do not enter anything here
Print the CSR
# cat owncloud.vorkbaard.nl.csr
Select every line in the CSR including the BEGIN CERTIFICATE HERE and END CERTIFICATE HERE lines.
Change the permissions of the .key file OpenSSL generated so only root can read it:
# chmod 600 owncloud.vorkbaard.nl.key
Move it to the private folder:
# mv owncloud.vorkbaard.nl.key /etc/ssl/private
Head over to your SSL provider’s website and start the certificate request process. They’ll provide you with a textbox to paste your CSR in.
Paste the CSR including the first and last lines.
The certificate vendor will need some information: your name, telephone number, payment method and a method to verify that you are indeed the owner of the (sub)domain you’re requesting the certificate for. These methods may include:
– you need to enter some file on your webserver
– you need to register a special subdomainname in your DNS
– you need to receive a mail at admin@ or some other static e-mail address.
After placing the order you may receive a verification mail with a code you need to fill out on the Comodo Security site, or some other SSL vendor.
If like me you placed your order with Xolphin.nl you’ll receive among other files a zip file containing four certificates:
Depending on the kind of certificate you purchased you may or may not receive intermediate certificates.
To install the certificate in Apache on Debian 8 you need to concatenate the four certificates in the exact order I mentioned: first your own cert, then the Domain Validation Secure Server CA, then the Add Trust CA and finally the Add Trust External CA Root.
I think this is silly but there you go. In Linux you can do this with the following command:
(which you should change to your own e-mail address) add:
Save the file and reload Apache:
# service apache2 reload
Reload the webpage in your browser: https://owncloud.vorkbaard.nl
To be honest it will probably fail because:
you made a typo somewhere
a file is not in the right place
you forgot to write https instead of http and also
forgot to do a2dissite 000-default
forgot to do service apache2 reload
you botched the concatenation of the bundle certificate
you overwrote your local hosts file
a combination of the above
There are a million ways to get SSL to work (and a million more to screw it up, do it wrong or both). The way I’ve described here is a simple one because there’s only one site in your Apache configuration and this entire server is dedicated to ownCloud. Feel free to experiment with other methods. They can be just as good and a lot of them will be better.
Make the Strict Transport Security warning go away
From the ownCloud site:
In /etc/apache2/sites-available/default-ssl.conf just after ServerName owncloud.vorkbaard.nl add:
Header always set Strict-Transport-Security "max-age=15768000;includeSubDomains; preload"
Enable the Headers module and restart Apache:
# a2enmod headers
# service apache2 restart
Deny access after three wrong passwords
We’re going to use Fail2ban to deny access to ownCloud after entering a wrong username. After ten minutes the user may try again. The purpose of this is to prevent password hammering: infinitely guessing a user’s password to break in to their account.
Fail2ban is software that can take action based on the contents of logfiles. You define combinations of software (based on that software’s logfile) and actions. These combinations are called jails in Fail2ban. The actions can include blocking access (using the firewall) and sending a notification e-mail to the administrator.
First we’ll set up the mail part, then Fail2ban. If you don’t care about mails from Fail2ban you can skip this part.
The mail part
My provider blocks outgoing traffic on port 25. They do that in order to prevent clients from sending spam. As a result my server can no longer send mail to me. My workaround is to have my server use my Gmail account to send out mail as Gmail’s SMTP server accepts traffic on port 587 instead of 25.
Debian 8’s default MTA is Exim4. Exim is capable of sending mail through Gmail but I find SSMTP easier to use with Gmail so I’m going to set up SSMTP. As a reference I will also configure Exim4 to send out mail directly. You should use one or the other: SSMTP or Exim4, not both. Luckily Debian will disable Exim4 for you if you install SSMTP.
The Package configurator will open. Select the following settings:
General type of mail configuration: internet site; mail is sent and received directly using SMTP.
System mail name: vorkbaard.nl (replace with your own domain or just your system’s hostname (i.e. owncloud.vorkbaard.nl). The worst that can happen is your mail will be blocked by your spamfilter. Just whitelist your server’s IP address or the sender’s address then.
IP-addresses to listen on for incomming SMTP connections: // leave blank
Other destinations for which mail is accepted: vorkbaard.nl (same as with System mail name).
Domains to relay mail for: // leave blank
Machines to relay mail for: // leave blank
Keep number of DNS-queries minimal (Dial-on-Demand) ?: No
Delivery method for local mail: Maildir format in home directory. Mbox format in /var/mail/ will also work but Maildir is what Debian advises so there you go. We’re not listening for incoming mail anyway, only outgoing.
In /etc/ssmtp/revaliases create an alias for root by adding this line:
Replace all instances of email@example.com with your own complete Gmail e-mail address. You may use your custom domain address here if you configured one with Google Apps. Replace P@55word with your own Gmail password or your app specific password if you enabled that.
Testing the e-mail functionality
Test your server’s mailing capability by sending a test mail:
Replace firstname.lastname@example.org with your own e-mail address. I tend to use a sequence number in my test mails so you can see exactly which test mails have arrived. -vvv means: be very verbose about what you’re doing. If something goes wrong you will probably be able to see what it causes it.
Setting up Fail2ban
# aptitude install fail2ban
Fail2ban uses template and differential files. This means you get a .conf file and create .local files which contain only the parts that differ from the .conf. Essentially just copy the .conf and make changes there rather than in the .conf. It makes upgrading easier. We’re not upgrading right now but it’s always nice to know why you do what you’re doing. Directly changing the .conf would work as well.
Remember the jail files? A jail in Fail2ban is a combination of logfiles and actions. Fail2ban can handle multiple jails. A filter is the part of the logfile Fail2ban should look for. Helpful users on the ownCloud forum have provided the regular expressions.
Create the file /etc/fail2ban/filter.d/owncloud.conf and add:
You may edit maxretry to your own tastes of course. This is the amount of seconds an IP address is banned. Afterwards the ban is lifted.
If you want Fail2ban to send you an e-mail when someone is banned change destemail:
mta = mail
destemail = email@example.com
action_ = just ban
action_mw = ban and mail
action_mwl = ban and mail with whois report and relevant log lines
I suggest _mwl but change it to your needs.
action = %(action_mwl)s
# fail2ban-client start
If it was already running:
# service fail2ban restart
Upon starting Fail2ban you should see any errors that were encountered. Pay close attention and troubleshoot when necessary. If you see no errors when starting Fail2ban then all should be fine. Fail2ban should also send you a mail to notify you that it has started. If you don’t receive this (and it’s not in your spambox as well) then you need to verify your server’s mail settings.
Now for the test. Open the ownCloud web interface and try to log in three (or whatever you set as the maximum) times with a wrong username-password combination.
If all is well you will now no longer be able to access your ownCloud site.
You should also receive an e-mail.
To manually unban a client do
# fail2ban-client set owncloud unbanip 192.168.1.2