Skip to content
Fragmented Development


This is a repository for the thoughts, notes, and achievements of Mr. Jacob Hume. It contains posts on a large variety of subjects, technical and otherwise.

Hiding parts of Oscar Commerce

I've been working on an eCommerce website using Oscar Commerce, and it has been an experience. One of the issues I've encountered is that Oscar has a tremendous number of features that I will never, ever need,

Luckily, there's an undocumented setting, OSCAR_HIDDEN_FEATURES, that is itself a hidden feature! The syntax is a simple list of different apps that you don't want to use:

OSCAR_HIDDEN_FEATURES = [ 'reviews', ]

I use it to hide the reviews app specifically, and I'm not sure if OSCAR_HIDDEN_FEATURES works for other apps, but it looks like it could be implemented by forking an app and adding the hidable_feature_name attribute to the application:

class MyHideableApplication(PreviousApplication):
    hidable_feature_name = "hideme"

If this stays undocumented, and I get to play with it a little more, I might do a full explanation of how it works - and how you can implement it in templates and such. is shutting down

It is time to shut down the FragDev GNUsocial instance; it will be taken down on June 30th, 2017. I've thought a lot about this, and due to some new developments in my life and the resources an instance requires, this seems like a good time to call it quits.

I've privately notified the FragDev users. They have all been wonderful, both before and after notification.

I am not sure whether I am leaving GNUsocial altogether. There are plenty of good instances out there to join, but the fediverse has become more representative of the planet as a whole recently. As Christopher M. Hobbes put it recently:

i like the pile of old crotchety hackers/duffers i started with here back when i first jumped onto statusnet. the federation of weebs have been a mixed bag, though.

That is putting it very, very democratically. I feel like the Internet, as with the rest of the world, has turned into a bit of a high-powered fecal cannon lately. While social medias of all kinds are not the cause of that, using them is the metaphorical equivalent of aiming that cannon towards yourself.

I've never been highly social, even during the days of IRC. GNUsocial's been the peak for me in regards that, and I need to decide if I want to keep it up or not.


It's rare that I have big news, so I'm just going to use an Adventure Time screenshot.

A screenshot of Jake the Dog, from Adventure Time, Season 4, Episode 19, 'Lady & Peebles'.

That's right! My partner and I are expecting some sort of baby in July! It's been hard to identify anatomical features, but it's humanoid for sure.

It is crazy stuff, but we're both really excited. So much for sleep and free time!

Keeping keys for SSH, and passwords for SFTP

My VPS has lots of different applications residing on it, and many people need to access it in various ways. Sometimes, tightening security for one group can negatively impact another.

One instance of this has been authentication with SSH. I prefer key-based authentication, for the added security and ease of use (once set up). However, this type of authentication doesn't work well for my SFTP users - they all have passwords, and generating and managing keys for them would be difficult at best.

OpenSSH *does * provide a neat trick for getting around this, through Match blocks. These blocks can specify a separate set of configurations for a subset of connections that "match" the criteria. You can match on an IP address, port, user... and a group!

I created a sftp group, and added all of my SFTP-only users into that group. I then tweaked my sshd configuration with the following changes:

PasswordAuthentication no
AllowGroups ssh sftp

Match Group sftp
    ForceCommand /usr/lib/openssh/sftp-server
    PasswordAuthentication yes
    [ other security hardening ]

This prevents ordinary SSH connections - users in the ssh group - from connecting with just a password, but allows it with SFTP users. It also allows me to restrict what is allowed for those users, because they obviously won't need things like X11/port forwarding.

It's not often I find this kind of nice, usable compromise where security is concerned - this was a very happy discovery!

MariaDB / mysql root password on Debian Stretch

I was a little perplexed when I installed a MariaDB server on my main desktop running Debian Stretch; it didn't ask me for a root password. This is a change from the previous Debians, which always prompt you to set the password during installation.

Not to fret, though. It seems like the way to login as root is to run the client as root with the sudo command.

Instead of the old mysql -u root -p command, you can just use sudo mysql and you're presented with the root prompt!

Much easier to do, as long as you know what to do. :P

For a full list of posts, feel free to check out the Archive!