Skip to content


Migrating ownCloud to NextCloud

ownCloud2small-left-arrow-clipart-1   nextcloud-logo

I’ve been a happy user of ownCloud for a few years now to dish shared calendar and contacts personally in addition to some image backup stuff with Android. I have no idea beyond the published reports of the split with the founder that started the Nextcloud variant, but it did seem like that is the future. So, getting over to it now made some sense to me. Here is what I did. YMMV.

  1. Backed-up up my ownCloud directory, mysql db, etc. via tar cvf and phpmysql.
  2. Moved my ownCloud directory off it’s usual path to something else (i.e. /var/www/owncloud to now /var/www/owncloud-old
  3. Downloaded the Nextcloud zip here. Unzipped it and gave it the orginal path of owncloud.
  4. Chmod’d and chown’d -R the permissions to get them the way I wanted of the new Nextcloud install.
  5. Moved the config.php from the old owncloud into the same dir of Nextcloud (from owncloudpath/config/config.php to netxcloudpath/config/config.php) and this was the old file I brought over from the previous OC folder.
  6. Hit the Nextcloud url path via browser and watched it go through the upgrade/update. It recognizes the situation and plays the required changes.
  7. I did have to go into admin on nextcloud and re-enable calendar and contacts for some reason. Not sure why. Maybe licensing or something?
  8. Took a while, but after I was able to access everything that was done in my previous owncloud.
  9. Really clean drop-in upgrade/sidegrade IMHO.

Some notes:

  1. I wasn’t on the very latest version of owncloud, but it still went fine. I was ballpark though (like 8.x something)
  2. I’m running on a 32bit Ubuntu 14.04 server. Apache, mysql, etc. Pretty standard from a few years back. I realize all the cool kids are nginx, but Apache has always been fine for me.
  3. I didn’t have a lot of other OC apps loaded. So, I wasn’t too worried about disabling stuff prior to NC.
  4. I am doing a lot of caldav and carddav stuff and that was back online right after. No probs.

I hope all goes well for you if you go down this route and move off ownCloud.

Stopping WordPress /xmlrpc.php Apache requests with UFW on Ubuntu

The WordPress XML-RPC ping attack is pretty annoying. For large sites and coordinated attacks, the XML-RPC issue can get insane. For my site, the /xmlrpc.php queries/post attempts are more of a log annoyance. Still, it is a hassle that I wanted to kill. The various WordPress plugins to help with this and the .htaccess commands really didn’t give me the closure I wanted, so it was time to leverage the bundled firewall, UFW, on my Ubuntu server.

Here is the problem. A quick grep of the /var/log/apache2/access.log will show the issue.


The various plugins for WordPress, the Apache .htaccess allow/deny commands or the rewrite don’t really stop the query to the webserver service but they do minimize the response traffic required. For most of these servers doing the attacks, there is no value in even having them connect to server anymore once they have pinged it to death for hours. These are not users, these are bots and I’d rather not even let them have a response.

I had very minimal firewall rules around web and mail services on this server prior to going after the xmlrpc.php attacks. But, it was time to add a few to the serial offending ips coming after my xmlrpc.php and WordPress. If your server is getting attacked by hundreds or thousands of IPs, than this method is more laborious that what you want to do. You can try to go with the fail2ban framework with WordPress and Linux. On my server running Ubuntu, the request problem is pretty contained to just a few IPs from time to time trying their luck with my WordPress xmlrpc.php. So, the path of blocking them outright is an easy thing to do.

The UFW community page at Ubuntu is great. I have always hated manual IPTables rules, so UFW is nice and clean to deal with.I reset ufw to default rules to clean-out all my old setups and start from scratch again. Add the rules you need for basic services and ports via the standard or advanced methods. There is also a GUI tool, GUFW, to handle this, but it has it’s limitations. You need to enable UFW if it isn’t active and add some rules to kill off the bad guys from even connecting to the server. If you can do this via a perimeter firewall, great. This is a home server, so the router in doesn’t have much beyond basic port forwarding functionality.

The issue with Apache and UFW is that Apache will read the rules in numeric order. So, any deny commands you do by IP or IP/port/service need to be ahead of the 80/http and 443/https allow rules. If you try to block and do your deny rules below the Apache2 allow rule for 80/443, it will not do anything for you. Get those deny rules up!

You can do this through the insert ufw command.

After pumping in a few of them, your rules will start to look like this:

First few rules via ufw status numbered
First few rules via ufw status numbered

I could have been specific to the IP and incoming port and only block http or https, but why with these IPs either evil bots or compromised servers. My allow for port 80 and 443 rules are further down the numeric list. Issuing a reload and watching the apache2 access.log will provide validation that these servers aren’t going to bug you anymore. You can also flip the ufw logs to medium to get a better sense of the activity it is deflecting if you need proof.

Term::ReadKey problems in Cygwin? Install the package vs. CPAN compile

I had an issue running Perl in Cygwin. I could install the modules I needed, but was unable to compile Term::ReadKey due to sgtty or some other challenges. I kept getting annoying messages around perl like this with “sgtty not found” and it seems to be an eternal issue. I found bug reports back to 2000!

Term::ReadKey in cygwin sgtty not found during cpan compile

I tried many different tactics within perl, but nothing worked. Turns out, there is a cygwin package you can install directly for this issue. You can run the setup.exe or setup64.exe for cygwin and select the


package to get the module going in perl under cygwin. You are also better-off long term on getting apt-cyg going in the cygwin environment to query and install packages easily in the environment and without the need to fire-up the setup.exe app each time you want to install a package.

Getting apt-cyg going in cygwin
Getting apt-cyg going in cygwin

Here is the install of Term::ReadKey via the setup apt-cyg:

Installing perl-Term-ReadKey via apt-cyg
Installing perl-Term-ReadKey via apt-cyg

HTC One with Cyanogenmod recommended settings

I’ve been running CM for almost six months now and have played with many different options and settings throughout and am very happy now with the following settings. This might be helpful for others thinking of ditching the stock Android and HTC Sense software.

1. Here is a snapshot of what the software versions look like tonight. I’m running CM 11.


2. I’ve found staying with dalvik runtime for the time being is still the way to go.

3. I have also played around a lot with energy profiles and found power save the best way to go.

4. For processor settings, I went back and forth often but keep coming back to the ondemand setting. Interactive is also great, but eats more battery for me and my usage for some reason.

Well, that is what I’m running now but it might change. I have tried Art runtime often, but have not yet found any advantages. The AT&T Visual Voicemail is buggy on KitKat, but I’m hoping they will eventually stabilize it again.

Hope this gives you another point of reference. I love the HTC One hardware, and CM really makes it sing.

Decent settings for mbpfan.conf for a MacBook 8,2


Fan-Control-Daemon has been working great for months on my MacBook Pro 8,2 running Ubuntu 13.04 natively but found it getting hotter and hotter all the time. So, I recompiled FCD from source and moved /etc/mbpfan.conf back to default but that really didn’t help. I had to mess with things a little. Of course, you mess with this on your laptop and you could fry it, so good luck to you. I’m not responsible for melted Macbooks.

But, here is my /etc/mbpfan.conf that I am happy with right now. I bumped the max fan speed up from the default of 6200 and messed with the temps a little while changing the check interval to 3 secs.