tmpfs for the download directory, great idea (that I have seen above too) !

At work I have all documentation put on a sshfs in the meantime that the team agree on a documentation tool for all (zillion of stuff deployed and still using the good'ol system).

And SSHFS lets you mount a directory only accessible to the user.

It is fun to see 'access denied' when you are root. :)

That introduces to distributed systems where authentication is omnipresent.

In the same spirit of the past 2 weeks thread promotion, let's have an insider's look at how you organize your machine. How do you tidy your home?
That's a simple question on its own, but knowing why you organize it that way can give insights on techniques others might not have previously considered.

I'll start with mine:


Looking back at it, I think it's a bit of a mess to have multiple "temporary" directories. But that's still a big improvement from my previous setup.

Somewhat on topic, I recently found this repo.

I'm kinda forced to keep all my school work in the magical cloud, so that's why my setup might look a bit empty.

(12-10-2020, 02:17 AM)venam Wrote: Looking back at it, I think it's a bit of a mess to have multiple "temporary" directories. But that's still a big improvement from my previous setup.

Why not just use /tmp?

(12-10-2020, 07:32 AM)opFez Wrote: Why not just use /tmp?

Each is "temporary" but for a different purpose, otherwise I would get confused between files. Also my /tmp is on tmpfs and I don't want these files to disappear after reboot, so it's out of the question.

I changed my $HOME a little bit since my last post in this thread:


Stuff that changed:

• ~/.profile and ~/.xprofile are where I set environment variables. ~/.session and ~/.xsession set my terminal and X session, respectively.
  
• ~/gpg/ is no more. I don't use gpg to save my passwords anymore, I use openssl now.
  
• ~/mail/ moved to ~/var/mail/
  
• ~/proj/, ~/files/ and ~/tmp have the same function they had.
  
• ~/usr/ is where I put binaries and other files of applications. Each subdirectory is for a different application. I use environment variables to set $PATH and $MANPATH to the corresponding directories in each ~/usr/*/.
  
• ~/skel/: Where I keep templates and skeleton, for example, ~/skel/c/ has the skeleton of C programs I write, etc.
  
• ~/trash/: Where I send my trash to, see fmutils for the scripts that manages the trash.
  
• ~/apps/: Where I keep .desktop entries for each application that has an entry in pmenu.
  
• ~/mnt/: Where I mount devices.
  
• ~/rules/: Where I keep configuration files (or rules files, as I call them) and databases for applications. For example, ~/rules/vimrc is my vimrc, ~/rules/rss contains the list of RSS I'm subscribed to, ~/rules/mime contains the mimetype-application associations that I use with my file-opener script xopen.
  
• ~/themes/: Where I put fonts, cursor themes, icon themes, Xresources, etc.
  
• ~/var/: Where I keep variable stuff. It is a new directory I added recently. It contains stuff like cache, browsing history, shell history, mail. I may move ~/trash/ there.
  

I'm working on ~/fav/ to keep bookmarks and on a script that symlinks entries on this directory to commonly used files.

I definitely think my ~/ could be a lot worse, lol.
(side note: not the full listing because there are a ton of files XD)

I am slowly moving toward using multiple users in /home just for myself:

* I have been the only one using my computer actively
* even if sharing it like a UNIX server, it makes sense to organise things like this (see below).
* UNIX user are not an unit to count human beings, but rather system users.
* static paths for data: can hardcode i.e /home/backup in custom scripts
* uniform permissions: cd /home && for x in *; do chown $x:$x $x; chmod 750 $x; done
* this reduces opportunity of human errors or doubt by having only 1 place in the whole system to apply protection for any kind for user data.
* does not mess with the software-specific permissions (no need to apply custom permissions to /var, /etc, /usr...)
* easy to design "operators" users that have access to these data, but without access in the other direction, by adding the i.e josuah user to these groups
* works well in shared work/perso environments: can have the convention to put a "$workplace" account on
all machines to use it on local scripts or user name, rather than ~/work/...
* same feature as these "cd wrapper scripts" for free with "su -l $user" that places you in the user of choice
and lets you come back to the original shell session with Ctrl+D (works with any shell ever).
* permits custom startup shells for specific purposes (see /home/weechat below)
* for free: I can now target each user's networking, quotas, permissions... from various configuration files

The real advantage in all that, is that it removes one important doubt: where will my data be, under which user.

In other words: welcome to the power of UNIX user permission management!

For instance:

/home/src - I git clone all media at the root of that directory.
That way, even if I run make on something freshly cloned from a compromised github account,
it only accesses /home/src and not (for instance) /home/josuah/Maildir

/home/pack - same as above, but for repos that I install with "make install".
I also have a small script to automate downloading and installing things here,
See z3bra's pm(8) for something nice.

/home/backup - as backups might contain sensible data from other systems, they
are isolated onto a specific user. Any system that stores backups have this
/home/backup

/home/weechat - a ~/.shell script is the start shell for this user that spins weechat
right away. From another user, "su -l weechat" attaches the current weechat session
using https://github.com/martanne/abduco or from remote, "ssh weechat@josuah.net"
and you are in right away. An IRC client vulnerability will not permit executing
/bin/sh nor accessing /home/josuah/Maildir.

/home/git - an example that you probably already do for being able to
git clone git@example.com:wonderful-project

/home/transmission - there is only one transmission-daemon running but multiple users
might be interested in it, so a dedicated user solves it. This also makes it a good
temporary storage to apply quotas on, so that the /home does not get filled with too
large torrent files.

/home/_sysupgrade - the (OpenBSD) system might itself make use of /home! It fits nicely
in this model where users have a purpose, rather than an human identity.

/home/{dn42,mirror,openstreetmap,...} - from times to time, I want to have a dedicated
location for some specific data, such as DN42 (not in that game anymore alas!) records
along with a dn42 user that can rsync network databases of any kind and what not, or
maybe some day I want to deal with these OpenStreetMap data files and store them in a
dedicated user with its own disk... I do not feel like adding a disk too far under
/home/.../.../.../ as I will never remember it! Anything special that happen with
permissions or mounts happens at a *single* point in hierarchy: /home.

That's all folks!

Remarks

Short note on /home/src related to OpenBSD: there is not enough room on /usr to fit /usr/obj, /usr/src, /usr/ports on my system, so these three are symlinks to matching subdirectories of /home/src/openbsd/.
This also fits OpenBSD's advise to have a separate dedicated user for compiling the system sources, eventually adding regular users for them.

Frequently encountered situation: I am in the middle of /home/josuah/Music, and want to quick git clone a github repo so I can actually grep the thing without waiting Github slow datacenters to move their arses. If it was too uncomfortable, I would never have done it. Since that move, I do: "doas su -l src; git clone $url" (doas might be sudo on Linux) and bam! I can resume to whatever I was doing in a blast without changing my shell history or working directory thanks to "su -l".

The whole thing might feel weird, or even flawed (I'd love to hear your impression :) if you think either!). And I am usually doubting on how to organise the rest in /home/josuah/. Everyone's posts above help me organise my own mess!

This mode of "tidy bazaar" organisation (overly flexible in order to never be messy whatever mess you throw at it) encountered here and there reminds me what Bogatin often says:

Quote:Do not consider that things to work thanks to how we design them, consider them to work in spite of how we design them.