antipaucity

fighting the lack of good ideas

putting owncloud 8 on a subdomain instead of a subdirectory on centos 7

After moving to a new server, I wanted to finally get ownCloud up and running (over SSL, of course) on it.

And I like subdomains for different services, so I wanted to put it at sub.domain.tld. This turns out to be not as straight-forward as one might otherwise hope, sadly – ownCloud expects to be installed to domain.tld/owncloud (and plops itself into /var/www/owncloud by default (or sometimes /var/www/html/owncloud).

My server is running CentOS 7, Apache 2.4, and MariaDB (a drop-in replacement for MySQL). This overview is going to presume you’re running the same configuration – feel free to spin one up quickly at Digital Ocean to try this yourself.

Start with the ownCloud installation instructions, which will point you to the openSUSE build service page, where you’ll follow the steps to add the ownCloud community repo to your yum repo list, and install ownCloud. (In my last how-to, 8.0 was current – 8.2 rolled-out since I installed 8.1 a couple days ago.)

Here is where you need to go “off the reservation” to get it ready to actually install.

Add a VirtualHost directive to redirect http://sub.domain.tld to https://sub.domain.tld (cipher suite list compiled thusly):


<VirtualHost *:80>
ServerName sub.domain.tld
Redirect permanent / https://sub.domain.tld/
</VirtualHost>

Configure an SSL VirtualHost directive to listen for sub.domain.tld:


<VirtualHost *:443>
SSLCertificateFile /etc/letsencrypt/live/sub.domain.tld/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/sub.domain.tld/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/sub.domain.tld/fullchain.pem
DocumentRoot /var/www/subdomain
ServerName sub.domain.tld
ErrorLog logs/subdomain-error_log
CustomLog logs/subdomain-access_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
ServerAdmin user@domain.tld
SSLEngine on
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder on
SSLOptions +StdEnvVars
<Directory "/var/www/cgi-bin">
SSLOptions +StdEnvVars
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
# allow .htaccess to change things
<Directory "/var/www/subdomain">
Options All +Indexes +FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
</VirtualHost>

Comment-out every line in (or remove) /etc/httpd/conf.d/owncloud.conf.

Move /var/www/html/owncloud/* to /var/www/subdomain.

Make sure permissions are correct on /var/www/subdomain:

  • chown -R :apache /var/www/subdomain

Run the command-line installer: /var/www/subdomain/occ maintenance:install

Fix ownership of the config file, /var/www/subdomain/config/config.php to root:apache.

In config.php,

  • change trusted domains from ‘localhost‘ to ‘sub.domain.tld
  • make sure ‘datadirectory‘ is equal to /var/www/subdomain/data
  • change ‘overwrite.cli.url‘ from ‘localhost‘ to ‘https://sub.domain.tld

Navigate to http://sub.domain.tld, and follow the prompts – and you should be a happy camper.

automated let’s encrypt ssl certificate renewal on centos 7

In my how-to for Let’s Encrypt, I gave an example script that can be called via cron (or manually) which will renew Let’s Encrypt SSL certificates under CentOS 6.

If you want to do it on CentOS 7 (which is what I am now running), use the following:

cd ~/letsencrypt
git pull
systemctl stop httpd.service
~/letsencrypt/letsencrypt-auto --agree-tos --keep --rsa-key-size 2048 --standalone certonly -m user@domain.tld -d domain.tld [-d sub.domain.tld [-d ...]]
systemctl start httpd.service

Now, what does this script do? Step by step:

  1. clear-out the last grab of the Let’s Encrypt git repo (there’s probably a better way to do this, but I don’t know what it is)
  2. go to root’s home (/root)
  3. clone-down the Let’s Encrypt toolset
  4. stop httpd (Apache in my case, though you might be running nginx or something else
  5. run the cert tool in automated form:
    1. agree to terms of service
    2. keep current cert if it doesn’t need to be updated
    3. key size of 2048 bits
    4. run the standalone webserver to verify “ownership” of the domain
    5. generate just the cert
    6. administrative email (optional, but “encouraged”)
    7. domain(s) to issue cert for (must be individually identified with successive -d flags; LE does not support wildcard certs)
  6. restart httpd

I set mine to run @weekly in cron@monthly is likely good enough, but since it’s “free” to run, running slightly more than is necessary seems good to me. Plus, if you’re getting SSL certs for many domains all being served from the same server, they may have different expiration dates, so running more often is better.

My crontab entry for renewing certs:

@weekly /root/renew-le-ssl.sh

it’s been 4.5 years

Since I last changed hosts.

I’m sticking with the same provider, but making a pretty big jump – from CentOS 6 to 7, from 2TB to 4TB storage, and 16GB to 64GB RAM.

Theoretically, you wouldn’t know this had changed at all unless you happened to catch it in the few seconds between DNS pointing to the old server vs the new one.

ssa, meet irs; irs, meet ssa

As you know, we adopted our second son last year (which finalized in Dec – woohoo!).

A couple weeks ago, we received Zeb’s birth certificate (which needs to be processed after an adoption), and applied for his SSN.

Earlier this week his brand spankin’ new SSN  card arrived – so I got down to finishing our tax return for 2015. Problem:

Rule Number: R0000-504-02
Rule Number Description: The SOCIAL SECURITY NUMBER (SSN or ITIN) and LAST NAME for Dependent 2 do not match the IRS e-File database. You will need to REVIEW AND MAKE CHANGES to the Dependent 2’s information before resubmitting your return.

Whahuh?

So I got on the phone to the IRS after some scary FAQ pages, it turns out that the IRS only gets data updates from the SSA every few weeks.

The very helpful lady who answered my call and helped me out told me to try again in a couple weeks, and it should go through with no issues.

At least there’s a reason for it to have rejected.

above the cloud storage

Who wants to go into business with me?

I’ve got a super-cool storage company idea.

Load up a metric buttload of cubesats with radiation-hardened SSD storage, solar power, and [relatively] simple communicaton stacks (secured by SSH or SSL, of course), and launch them into orbit.

You think cloud storage is cool? What about above-the-cloud storage?

Pros:

  • avoid national jurisdictional rules, since the data will never be housed “in” a specific country
  • very hard to attack physically
  • great reason to use IPv6 addressing

Cons:

  • expensive to get the initial devices into orbit
  • software maintenance on the system could be annoying
  • need to continually plop more cubesats into orbit to handle both expanded data needs and loss of existing devices due to orbital degradation

Who’s with me?

meetings

The author of a recent Medium post is so close to right, it’s scary. Gary says the best thing you can do is to cut your meeting length in half.

And that is a phenomenal step. One that needs to happen. But one that needs to happen in conjunction with an even more monumental shift.

Change the start time of meetings to something “weird”.

Don’t start on the hour or half hour. Don’t even start on the quarter hour.

Start at 10 past or 10 til, and go for 15, 30, or 45 minutes – with a hard cut off. Just like college classes. Oh – and just like class days when all you had was a test, as soon as your part of the meeting is over, leave. You may have to wait to leave until the end. But once your piece is done, just like when you finished your test, walk out and get on with your day.

dave winer is wrong

Or maybe he’s right. But for the wrong reason.

Over on Medium, which is where I saw his post, Dave said:

“The problem of requiring HTTPs in less than 140 chars: 1.Few benefits for blog-like sites, and 2. The costs are prohibitive.

There’s actually a #3 (sorry) — 3. For sites where the owner is gone the costs are more than prohibitive. There’s no one to do the work.”

While this was more-or-less true-ish in times gone by, with the advent of truly-free SSL (and not merely the manual free edition you could get from StartSSL) from Let’s Encrypt (see my how-to), automated, hands-off maintenance of your SSL-iness is possible (and encouraged).

There are, potentially, good reasons for saying SSL won’t be required. But blaming costs, upkeep, and “few benefits” are not among them. If anything, SSL-ifying your blog will help with some (not all) attacks launched against self-hosted/-managed services where login data can be otherwise captured in plaintext.

Dave, I like you. But you’re wrong on this one.