Linux

+1 to the other replies here recommending starting over with a single partition.

However, if you want to apply some duct tape to fix your immediate problem without reinstalling, to point a filesystem location (path) from a full partition at a location on another partition which has available space, two options you have are symbolic links or bind mounts. The former is conceptually a little bit simpler, but it won't satisfy some applications. The latter is a bit more complicated, but the unix stack exchange answer i just linked to has a good explanation of the ins and outs (but on Linux you should ignore the parts of that answer about bindfs and nullfs and just follow the instructions under Linux bind mount). And if you want a bind mount to persist after a reboot, be sure to follow the instructions there about adding it to your /etc/fstab file.

• Make the var partition bigger (how big is it?)
• use systemd and set a max size of the log files
• use logrotate to set a max size
• if auth.log is too big then it's probably a server so you might want to log to a syslog server instead of storing it on the system
• or you set the SSH port to something different to reduce noise
• or you disable logging for nonexistent users
• or you set up fail2ban to stop bruteforce
• or you set the SSH daemon spawn settings so it doesn't allow brute forcing
• ...

there's basically endless solutions for this problem based on the actual source of the issue. What's the reason for you needing to delete the auth.log?

Having a separate partition is a good idea and funny enough it can help you in this issue. If you try to reinstall the system, you can format the other partitions and leave /home untouched, so you will have a fresh system but keeping all your personal data as it is; that's the main benefit of having multiple partitions.

Next time, you should just make /var bigger according to your own experience. Other people only have 2 partitions: / as a 20-40 GB one (or bigger, this is according your needs) and the rest of your HDD/SDD for /home. Another tip is that when you're re-installing the system, use a new nickname, otherwise the new system will try to use all the old config files in your old account, and finally, if there's very important stuff in /home, definitely make an outside backup, there's always the chance of misreading something or ticking the wrong box.

Boot into a livedisk and transfer some space from a bigger partition to var. I had the same problem tbh, and iirc I just chose to go with /home and everything else as 2 separate partitions, didn't see the value of having /, /usr, and /var as 3 different ones (plus fstab has caused me some issues whenever one of my disks is slower to come online than the primary, so I just figure the less partitions the better)

This doesn't solve your present problem but maybe it helps to avoid it in the future.

Instead of physical volumes, you could use thin provisioned logical volumes. LVM is the word here. These would allow you to maintain volume division without fixing the sizes rigidly.

Another way to do this would be to use a BTRFS filesystem, and it's subvolumes as 'real volumes'. The semantics would be the same.