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.
Can Indexette write to this post file?
Check line 3 at https://stevenrosenberg.nfshost.com/documents/ode/2020_1106_ode_indexette_test.txt
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.
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:
local_umask=022
If the /data/state
directory works with 755 permissions, you will see this post.
If the /data/state/Indexette
directory works with 755 permissions, you will see this post.
If the /data/state/Indexette
directory works with 775 permissions, you will see this post.
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).
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.
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.
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.