Title photo
frugal technology, simple living and guerrilla large-appliance repair

Regular blog here, 'microblog' there

Many of my traditional blog post live on this site, but a great majority of my social-style posts can be found on my much-busier microbloging site at updates.passthejoe.net. It's busier because my BlogPoster "microblogging" script generates short, Twitter-style posts from the Linux or Windows (or anywhere you can run Ruby with too many Gems) command line, uploads them to the web server and send them out on my Twitter and Mastodon feeds.

I used to post to this blog via scripts and Unix/Linux utilities (curl and Unison) that helped me mirror the files locally and on the server. Since this site recently moved hosts, none of that is set up. I'm just using SFTP and SSH to write posts and manage the site.

Disqus comments are not live just yet because I'm not sure about what I'm going to do for the domain on this site. I'll probably restore the old domain at first just to have some continuity, but for now I like using the "free" domain from this site's new host, NearlyFreeSpeech.net.

Sun, 14 Jul 2019

File permissions and ownership that make Ode's Indexette work on a Debian Buster server

This was easier on Hostgator, where everything is "owned" by my user account and everything works.

To get Ode addins to work, the /data directory is owned by my user and is in the www-data group.

The /data/addins/state directory has the same ownership and permissions (755).

The /data/addins/state/Indexette directory is owned by www-data and is in the www-data group and has permissions 755.

The files created by Indexette in /data/addins/state/Indexette are aux_index_file and primary_index_file. They are owned by www-data and are in the www-data group. Their permissions are 644.

Set umask in vsftpd so incoming files have 644 permissions

If you are setting up an FTP server (I'm using vsftpd in Debian Buster), setting the umask is the way you get incoming files to "take" the right permissions.

For text files, I like the permissions to be 644, which is rw-r--r-- (read-write for user, read for group, read for the world).

To get this in vsftpd, uncomment this line:


Ode Indexette state directory test No. 3

If the /data/state directory works with 755 permissions, you will see this post.

Ode Indexette state directory test No. 2

If the /data/state/Indexette directory works with 755 permissions, you will see this post.

Ode Indexette state directory test

If the /data/state/Indexette directory works with 775 permissions, you will see this post.

Sat, 13 Jul 2019

Permissions are hard

Figuring out file and directory permissions on a server is hard.

You have to balance security with functionality (meaning what are the most restrictive permissions you can set and still have everything work).

Shared hosting does take care of a lot for you

As I build my own server — and this would be the same for a cloud VPS or a local computer, there is a lot to set up and configure.

Shared hosts like NearlyFreeSpeech.net (which I will be using more soon) and Hostgator (which I've used for years and will probably be using less) take care of many things in a safe and secure way.

Setting up your own server is very much like reinventing the wheel. It's better if you like making wheels, have used a lot of wheels, fixed broken ones and rebuilt old ones.

Sometimes you want somebody else to fix your wheel. Other times you want to do it yourself. Both ways are OK.

Setting up FTP on my Pi

Running your own servers — be they VPSes on Google, AWS or Digital Ocean, or Raspberry Pis in the closet — is a learning experience. You have to put on your sysadmin hat and get to work.

Today I'm trying to figure out the ftp server. I've used a hundred of them but never installed and configured one. The hardest part to figure out is the SSL encryption.

If you see this file, it means I've made some progress.

Wed, 26 Jun 2019

My current fix for the Conexant-Flow.Exe-Firefox issue

The problem for users of Windows laptops using the Conexant audio driver that makes Conexant's Flow.exe program eat large amounts of CPU when the Firefox web browser is running has not been solved by "conventional" means.

And in order to be part of the "solution," should one ever come, I filed a bug with Mozilla on the issue.

There have been many fixes proposed for this problem, which only seems to manifest itself on my HP Envy laptop while running Firefox. You hear the fan rev up almost immediately and then can see both Firefox and Flow.exe climb in the amount of CPU they are taking, combining for a total of about 60% on my laptop.

This has been going on for many months, and a couple of days ago I got tired of being forced to run Chrome. It's not right that I can't use the privacy-loving Firefox on my Windows 10 laptop.

So I went back to one of the "fixes" that works:

To keep Flow.exe from running constantly and stealing excessive CPU while you are using Firefox or any other program, just change the name Flow.exe to something like _Flow.exe (I just added an underscore) so the Conexant audio system can no longer "find" it. Trust me, sound works fine without it. Why it's there at all is a mystery.

You can find Flow.exe in this folder: C:\Program Files\CONEXANT\Flow. Just rename Flow.exe as _Flow.exe (or whatever you want; changing its name is enough to keep it from running). I'm not sure whether or not you need to reboot after this, but it couldn't hurt.

Once you rename Flow.exe, You will get a popup every time you restart the PC warning you that you need to reinstall your Conexant audio software because Flow.exe is missing. Ignore this nagging box. I'd like to send Conexant a few popups, or maybe I should send my good wishes to Logitech, the company that bought Conexant a few years ago. Both are garbage. They're certainly not seeing what I'm saying about them on Twitter and consequently falling all over me to fix anything. No, it's radio silence. F&^% 'em.

Tue, 25 Jun 2019

Unison works between Ubuntu and NearlyFreeSpeech.net's FreeBSD, so blog migration is a go

As long as I've been using Unison, I've been running version 2.40 because that's the newest package I can get for CentOS 6, which is the Linux system that my current shared host runs.

The first thing you learn about using Unison to synchronize files on a server and a number of desktops, is that Unison likes to see the same version on both sides of the "transaction." If you have different versions of Unison, or even the same version compiled with a different version of Ocaml, it's probably not going to work.

I haven't even figured out how to sync from Windows to Linux with the same Unison version on both sides. It probably has something to do with Unix file permissions vs. Windows file permissions.

But from Linux to Linux, you need the same Unison, compiled with the same Ocaml, on both sides. Even in Fedora 30, the project doesn't package "newer" than Unison 2.40, so that's what I run locally.

See if you can wrap your head around this: Forward-thinking Fedora packages Unison 2.40, but Debian and Ubuntu have been packaging 2.48. And the current "stable" version of Unison is 2.51, which seemingly nobody packages anywhere.

But NearlyFreeSpeech.net offers Unison 2.51, which the admins likely built from ports for their FreeBSD infrastructure. Even OpenBSD offers Unison 2.51, and you can get it with a binary package.

Let me tl;dr this: I downloaded the source for Unison 2.51, untarred it in my Windows 10 WSL (which is running Ubuntu 16.04), used apt to install Ocaml, untarred the Unison sources and used make UISTYLE=text to compile it. Then I had to make a .prf configuration file for the new site (building off my old .prf) and play around until I got it right. It worked, and now that I can successfully use Unison to sync between the Ubuntu 16.04 WSL in Windows and NFSN's FreeBSD system, I am free to move my Ode sites over there.

Why do I use Unison? Ode's has an extension that allows the server to put its own timestamps on post files after they are uploaded, so if I only pushed one way, say using rsync, the local files wouldn't have the timestamps that are on the server versions. Unison checks in both directions for file changes and reconciles them. Git is another way to do this, and it's something I might explore in the future, though I'm more interested in syncing the two filesystems than I am in version control, and that's why I decided to use Unison in the first place.

I'm thinking of giving up on /blog: I originally set up this blog with a /blog subdirectory because I couldn't figure out how to make the /cgi-bin/ode.cgi part of the URL "disappear" via Apache's .htaccess any other way. Since then, I have figured out how to do that, and I might either dedicate http://stevenrosenberg.net to this blog, or more likely put it on a subdomain like blog.stevenrosenberg.net. That MIGHT mean breaking the Disqus comments, but I could probably save them. Even so, I've been thinking about giving up on outside-hosted comments and instead creating links to Reddit to allow for discussion of entries on this blog.

Changing the URL could break all the old links. I could set up redirects in the Apache configuration, or I could just let it go. Or I might keep the old URL along with /blog.