(also, many commands have some internal --help)

but I better shut up now as it's time for @ArturMeinild's lesson!

thank you all!

Thank you!

thanks for another awesome lesson!!

Thanks @Zanna

Are we having another lesson next week, or is this the last one for a while?

thanks @Zanna

thanks a lot @Zanna

@EliahKagan we might have to take a small break

@EliahKagan I guess Zanna is taking a break... she mentioned it somewhere..

this is the last lesson for now. I hope to do some more in January or later

@technastic_tc yes I mentioned in AUGR I will take a break from giving lessons for some time

@Zanna ok.

thanks @αғsнιη @technastic_tc @terdon @EliahKagan @BeastOfCaerbannog @ArturMeinild @SirGuelph @Kulfy for participating in the lesson and making it a great success

@jokerdino :)

<3 to all thank you for your patience!

Thank you :)

Need a break before I continue?

maybe 5-10 min

I don't think it's going to be that long today - more a continuation of last session

sorry for overrunning so much

Yup

@jokerdino sounds good

Lets be back in 10

thanks :)

Thank you Z

Thank you @Zanna!

:) :) :)

Thanks @Zanna

thanks for joining @karel

:)

Please say when you're back and ready

I thought this lesson would be a follow up on the last one, to answer some questions and hear some experiences

I'm here.

And maybe elaborate a bit on some topics from my handouts

I'm here.

For those who didn't attend last, this is the link: pastebin.com/siaGhWNs

At any point during this session, please ask for clarification, and I'll try and answer - or maybe someone else can :-)

I'm here too

here and back

Good - just waiting for the last couple of folks..

Ok so did anyone try something with cron and/or rsync since last time - and did it work? If no, what didn't work?

Let us hear your experiences, if you got any :-)

Or if you have any questions regarding the topics, please ask.

cron worked wonderful

Good to hear!

haven't tried out rsync though

I think I would elaborate a bit on cron actually

when a new cronjob added by crontab -e; where that job exactly written? I mean in which file path?

@αғsнιη Can you elaborate?

Generally, when using cron you should use absolute paths

So all filenames, commands etc. (except those in path) should always be full, absolute names

Or was there something specific? Maybe try to give an example if this didn't answer.

@αғsнιη is asking crontab -e is editing which specific file

as we all know, everything is a file in linux

oh

when we type 'crontab -e' then define a job, these job actually writing into which file? because we only know editor opens a list of jobs, I'm asking the location of these jobs maybe somewhere in a file?

but when using crontab -e you open it and can see the list

And using crontab -l the contents is displayed

But this file should only be edited with crontab -e, and not manually

User crontabs are stored in /var/spool/cron but it is not recommended to edit them there and that directory is owned by root without even read permission for other users.

@EliahKagan Thanks for elaboration

But remember that "user crontab" as we went through last time, is only one of several types of crontabs

Aside from user crontabs, there are some system-wide cron definition files

One example is the file: /etc/crontab

@EliahKagan Running crontab -e creates a temporary file, which is then edited. When you quit the editor, it will create a file in /var/spool/cron or apply changes to an existing file there or do nothing, depending on whether or not your user crontab existed already and whether or not you made any changes in the editor.

Another example are the files located in the directory /etc/cron.d

I feel a sort of reference table of cron's files could be useful

thanks @ArturMeinild @EliahKagan

(I should've said more specifically that user crontabs are stored directly inside /var/spool/cron/crontabs.)

@Zanna Actually, you kind of get that with the command ls /etc/cron*

This lists all files and dirs that have something to do with cron, except for the user crontabs we talked about last time

oh, cool!

But right now, I would just like to point out that the syntax of the systemwide cron definitions are a little bit different than the user crontab

oh

@Zanna Although it's not a table, the "NOTES" section of cron(8) gives all the locations (including for user crontabs).

System cron definitions have this format:

[Minute] [Hour] [Day of month] [Month] [Day of week] [User] [Command]

@EliahKagan thanks! :)

The user crontab had this format:

Sorry, [Minute] [Hour] [Day of month] [Month] [Day of week] [Command]

The "user" field is unique to system crontab

Which kinda makes sense

yes

So in the file /etc/crontab you can put any number of lines for cronjobs, and define which user it should run as, including root

there are lots of system users it might be useful to run jobs as, right?

And in the dir /etc/cron.d you can make any file, and include a cronjob definition there

@ArturMeinild with the same format as /etc/crontab?

@Zanna Yes

@Zanna I usually run as myself or root

I'm not aware if there are specific system users where it would make sense, but I guess there is

is there any priority of running for the jobs when it's systemwide and when it's user level? which jobs are running at first or maybe they are running in parallels?

@αғsнιη Actually I'm not sure - or if everything is just fired at the same time

I mean, fired when it's set to go - and if 2 jobs are set to run at the same time I guess they run in parallet

*parallel

Also, someone asked what would be obvious tasks to do with a cronjob

And I can only answer for myself- and you're all welcome to add to this

Remember, the scenario is that I run a couple of home servers

So the systemwide cronjobs I'm running are the following:

no, I'm not talking for the same job in both systemwide or user level; I'm asking if there are some system level defined jobs and some user level, so cron daemon execute system level jobs at first priority then user level or what (assuming they have same running time)?

@αғsнιη I don't think there is any priority - I think they go in parallel - someone correct me if I'm wrong

However, since you can define runtime down to the minute, you can define the order in which scripts are run by the time they run

For instance, my reboot script runs 1 hour after my update script

a quick look at Unix & Linux suggests cron jobs with the same timing run in parallel if possible

The other way around wouldn't make sense

but further research needed to confirm

@Zanna Thanks

@ArturMeinild very useful list

@Zanna Just some examples from the real world (or my real world at least) :-)

(I'm interested in ZFS, if you want to talk more about it)

Yes. cron will start the jobs in some order, and I'd be interested to learn what order that is for jobs scheduled for the sametime... but the order does not actually matter hardly at all, because cron does not wait for one job to finish before it starts the "next" one.

@EliahKagan I think that's a good point - if you need a very specific order, either do it by timer, or program some conditions into your scripts - for instance 1st script leaves a file that 2nd script checks for to continue

@Zanna re: ZFS - I'm by no means an expert

But ZFS is really easy and very cool for storage

I wouldn't run it as system disk, but for NAS, definitely

It's incredibly reliable

I think I read that it was useful for preserving stuff, like images, that could somehow degrade over time (but how does that work?)... archival storage

Yes - it has many features for data preservation and recovery

And most of them automatic, so you mostly don't even have to worry about it

nice!

To put it very short, is has in-build hash-checking of all files - and support for Raid-redundancy

so basically, if the filesystem ever detects the checksum of one of your files doesn

*doesn't match, it can recreate the file as it should be

so, what does the trimming and scrubbing in your cron job do?

Trimming is because it's an SSD raid

so like normal SSD trim - but for the ZFS pool

and scrubbing is a monthly integrity check - just because

And I keep 1 month of daily snapshots

so with a single command you can always roll back to an earlier filesystem state where you have a snapshot

exemplary backup haha

I think that's enough about ZFS for now, I could go on and on :-D

@Zanna I would say it's a good addition to backup ;-)

If your server catches fire, you're still screwed - but if not, you're good :-)

hahaha

Ok I think last point for today - something else we didn't have time for last, and one example - SSHFS

SSHFS can be used to mount a filesystem over SSH

First we install it: sudo apt install sshfs

And then, we can mount a remote folder on a local one:

sshfs artur@myserver:/mnt/backup /mnt/backup/remote

The syntax is: sshfs [remote source] [local target]

@ArturMeinild We don't get many questions about it and I find it hard to research. I was hoping that more people would try giving lessons to reveal a glimpse of their untapped expertise :)

(The folder /mnt/backup/remote must exist and be empty)

@ArturMeinild at remote side for the "artur@myserver:/mnt/backup" path, there should be any changes to config?

@Zanna Hehe point taken into consideration

@αғsнιη Absolutely no config whatsoever is needed for SSHFS - not for me at least

I just fire one command when my server starts to mount the remote folder - that's the beauty of it

Now let's say you have mounted the remote folder /mnt/backup on myserver to the local folder: /mnt/backup/remote

hmm, I see

Now we can rsync over SSH, but use the local path instead

rsync -zav /home/artur/{documents,pictures,videos} /mnt/backup/remote

This will then be copied to /mnt/backup as if using SSH with artur@myserver

Did that make sense?

yes

I have one usecase for SSHFS currently - and there may be others

wait, when it's mounted locally then we can use mv, cp as well, right?

I have a primary server and a support server (raspberry pi)

@αғsнιη Of course

I would like to have all log files of all my servers available on my primary server

so I made the dir /var/log/xo where xo is the name of my secondary machine

And mount with this command: sshfs artur@secondary-server:/var/log /var/log/xo

so now the logs of my raspberry pi is available inside /var/log/xoon my main server

/var/log/xo

This is an alternative to using remote logging, and I think this is easier

So the logs are stored locally on my ras-pi, but available as a network dir on my server

And it's very easy to use

Ok I think that's it for now.. :-)

that sounds very handy!

Anyone still here? ;-)

@Zanna :-)

I am still here. :)

yes, it is good

thank you @ArturMeinild

thank you so much for giving the lesson @ArturMeinild

You're most welcome

Thank you!

Is there time for questions?

@ArturMeinild what is the command to umount the sshfs mounted path?

it is on df list

Sure question if you have any?

Let's see if I can answer

@αғsнιη You can just use umount as with other kinds of mounts. You don't have to run it as root (just as sshfs need not be -- and should not usuallybe -- run as root).

@ArturMeinild I've just noticed a problem with sshfs when the local and remote systems don't agree about the group ID of the user's primary group.

ek@Grr:~$ mount | grep sshfs
arg:backup on /home/ek/backup/remote type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=1000,group_id=1001)
ek@Grr:~$ rsync -zav ~/{Documents,Pictures,Videos} ~/backup/remote
sending incremental file list
rsync: [generator] chgrp "/home/ek/backup/remote/Documents" failed: Permission denied (13)
rsync: [generator] chgrp "/home/ek/backup/remote/Pictures" failed: Permission denied (13)
rsync: [generator] chgrp "/home/ek/backup/remote/Videos" failed: Permission denied (13)

@EliahKagan You're right that SSHFS is rather picky about permissions

It has to be the same user and group ID on both sides

I'm not sure how properly to solve this.

Ah.

I think that's just how it works

Okay.

@EliahKagan I'm not sure if it's because of rsync that is trying to change the group of the file it's copying while no that group_id in destination side?

Is it because UID and GID was different between the machines?

Yes. Or, specifically, the GID was different. The UID was the same.

ek is the user I created during installation and has user id 1000 (on both systems), but on the client the ek group has group id 1001, while it has group id 1000 on the server. I don't know why ek has gid 1001 instead of 1000 on the client. Maybe some weird thing specific to the Calamares installer (since the client is Lubuntu which uses that).

Hmm okay

try without preservation flags

@user.dz Good idea - try resync without the -a flag, which is contains UID and GID preservation

*rsync

@ArturMeinild for your information to edit your messages text you can hover mouse on your messages and an arrow button will appear, click there and select "edit"

It actually works even as run, it just gives the error. Like, it does everything I want it to do (copying/updating files).

@αғsнιη Thanks - I haven't chatted much here :-)

However, if the server had a group 1001, then I think it would try to change the GID of the files to that -- and if my user on the server were a member of that group, then the operation would presumably succeed -- which I wouldn't want.

@EliahKagan That's odd - so it's actually just cosmetic

@ArturMeinild no problem

Yeah but as I said, SSHFS can be a bit picky

@ArturMeinild I've tried a variation on that where I keep everything -a does except the GID part, and that works. Thanks -- and thanks @user.dz.

ek@Grr:~$ rsync -zav --no-g ~/{Documents,Pictures,Videos} ~/backup/remote
sending incremental file list
Documents/
Documents/greeting.txt

sent 227 bytes  received 41 bytes  536.00 bytes/sec
total size is 17  speedup is 0.06

@ArturMeinild thank you for the lesson; and thanks everyone, I have to leave; bye

@EliahKagan Nice, that's good to know!

(That is, I added --no-g as a subsequent argument, rather than removing -a, so that I would still have -rlptoD, as implied by -a.)

@EliahKagan Good solution! :-)

Yeah thanks for now everyone - later !

Thanks again for the lesson!

Yeah Thanks for lesson and hints folks

cp may have similar option, cp -a shows warnings

Yes, I do get corresponding messages from cp -a with those files.

ek@Grr:~$ cp -av ~/{Documents,Pictures,Videos} ~/backup/remote
'/home/ek/Documents/greeting.txt' -> '/home/ek/backup/remote/Documents/greeting.txt'
cp: failed to preserve ownership for '/home/ek/backup/remote/Documents/greeting.txt': Permission denied
cp: failed to preserve ownership for '/home/ek/backup/remote/Documents': Permission denied
cp: failed to preserve ownership for '/home/ek/backup/remote/Pictures': Permission denied
cp: failed to preserve ownership for '/home/ek/backup/remote/Videos': Permission denied

but it does make a copy, and changes group and user

It makes a copy.

See you & have nice day

Cya! :)

@terdon hahaha that's cos I was doing a bad job of it :) Thanks a lot for your help throughout all the lessons!

thank you @EliahKagan for all the corrections and illuminations :)

:)

@Zanna This is because small files take up more space on disk than the size of the file. Most files do, but with small files the amount they take up can be many times the size of the file.

is it because they use inodes?

No, neither I nor ls -l are talking about space taken up in the inode table.

Empty files take up zero space.

But a file with one byte will, on an ext4 filesystem set up in the usual way, take up 4 kilobytes.

(That is not at all related to the "4" in "ext4" though. :)

File contents are stored in zero or more extents.* The space taken up on disk for the file is the sum of the sizes of all the extents.

[* I've heard this is not strictly speaking universally true, and that there is some other way that the contents of files can be stored, in some filesystems. I don't know how that works.]

ek@Kip:~/playroom$ printf a >smallfile
ek@Kip:~/playroom$ wc -c smallfile
1 smallfile
ek@Kip:~/playroom$ sudo hdparm --fibmap smallfile

smallfile:
 filesystem blocksize 4096, begins at LBA 8388608; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0  128519448  128519455          8

@EliahKagan haha

@EliahKagan ok

I should've said kibibytes.

instead of kilobytes?

Yes.

ls defaults to units of 1024-byte blocks.

And when a filesystem is created with a blocksize of 4096 bytes (as hdparm reported, and as is usually the case with ext4), that's 1024 * 4 = four kibibytes.

I just have the bad habit of saying "kilobyte".

In most cases it is not necessary to be root to list a file's extents. I don't know why hdparm requires that for --fibmap (as opposed to trying and only reporting an error if it fails). But hdparm --fibmap seems to be doing some other stuff too, judging by how on one system I first get a "SG_IO: bad/missing sense data" warnings about the device when I run it.

But hdparm comes with Ubuntu so I figured I'd show it using that.