piCore 7 - motd, cron and minidlna persistance oddness

[Cyclic]

Hi,

I must have missed something and I have RTFM'd. I'm running piCore 7 on a RPi 2B. I'm trying to persist motd, crontabs and minidlna files.db in /opt/.filelist.lst. I have these persisted successfully in VirtualBox using a current version of tinycore.

My appended entries in /opt/.filetool.lst are:

etc/motd
var/spool/cron/crontabs
var/cache/minidlna/files.db

I am running minidlna and cron in bootlocal.sh: minidlnad and crond -L /dev/null 2>&1

both services appear to start up correctly on boot.

I want a custom motd because if a hacker succeeds in brute forcing ssh then I don't want to advertise the flavour of linux I'm using.

crontabs: is not persisting, each reboot I have to crontab -e and recreate the cron entry (it does not exist).  If I crontab -l after boot then picore complains that tc does not exist (fair enough the file has not been persisted).

var/cache/minidlna/files.db: After reboot, each time the service starts it recreates files.db and re-scans my external usb hard drive for files.  Now I appreciate this is in a cache folder so perhaps I should accept it will be unpersistable - if that's a real word.

I must be missing something (I have samba4 persisting successfully) but can someone tell me - what have I failed to account for?  Perhaps I have to config these files to a more persistable area?

Many thanks and best wishes,

Cyclic

[bmarkus]

Did you make a backup?

[jgrulich]

Hence all these files are working dir files, not statical setup, read only, don't use the "backup" for persistence, but redirect these files to the /mnt/mmcblk0p2/tce. I'm using it and it works well.

[Cyclic]

Thank you for your replies.

bmarkus: Yes, I've been running filetool.sh -b after making config changes.  I left it overnight - then ran filetool.sh -d before filetool.sh -b to make sure it had the intention of backing up those files.  On reboot, no crontabs and minidlna has recreated that files.db file again and is proceeding to re-scan my drive.

jgrulich: I'm not quite sure what you're driving at? /mnt/mmcblk0p2/tce contains mydata.tgz which is the compressed back up - but where would I put those files if I want them restored?

I suppose I could work around the issue by copying those files to the home directory, backing up and then copying them back over in bootlocal before starting any services it's just not as neat and tidy.

[Cyclic]

Ok.

So this appears to be a permissions problem.  With minidlna, changing the database directory from db_dir=/var/cache/minidlna to db_dir=/home/tc in the config file (etc/minidlna.conf) appears to have resolved the issue.

However, /etc/motd appears to be read only on boot - and I suspect that when tc tries to restore the backed up file it fails.

So I suppose the question now is, how do I change the permissions on the booted OS?  Where's that compressed file?

Best,

Cyclic

[Greg Erskine]

hi Cyclic,

I can confirm that motd and cron can be changed and restored using standard piCore methods.

1. Add to /opt/filetool.sh
2. sudo filetool.sh -b

cron is started via a boot code.

regards
Greg

[Cyclic]

Hi Greg,

I thought so too because I've set up tc on my laptop with a custom motd so to double check I just installed tc on VirtualBox and did exactly what you suggested:

1. Modified /etc/motd
2. Added etc/motd to /opt/.filetool.lst
3. Ran sudo filetool.sh -b (I hadn't been running it with sudo on piCore)

On VirtualBox with a tinycore installation this works perfectly - changes to motd are preserved.

So then I booted my RPi which is running piCore 7 and did exactly the same thing (twice to make sure) but after reboot the modified motd does not persist - I just get the standard one.

Now I compared the permissions on motd on both systems and they are identical so this appears to be a quirk of piCore 7.

Maybe I should just use an older version of piCore?

Best,

Cyclic

[Cyclic]

Ok, an update.

Finally got it working - I moved the etc/motd line in .filetool.lst further up the file and it now works.

Everything after a line in .filetool.lst was failing to back up.  The line was:

proc/sys/fs/inotify/max_user_watches

So I've removed that line from .filetool.lst and now it's all good.  I'm not sure why backing up proc/sys/fs/inotify/max_user_watches would cause filetool.sh to fail - perhaps someone can shed some light on that?

Either way, thank you very much everyone for your help and time - it is very much appreciated.

Best,

Cyclic

[Greg Erskine]

Are you getting the "Done" message after running "sudo filetool.sh -b"?

Check /tmp/backup_status for error messages.

[Rich]

Hi Cyclic
The  /proc  file system doesn't strike me as a place you should be trying to back up files from. An excerpt from:
http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.html

/proc is very special in that it is also a virtual filesystem. It's sometimes referred to as a process information pseudo-file system. It doesn't contain 'real' files but runtime system information (e.g. system memory, devices mounted, hardware configuration, etc). For this reason it can be regarded as a control and information centre for the kernel. In fact, quite a lot of system utilities are simply calls to files in this directory. For example, 'lsmod' is the same as 'cat /proc/modules' while 'lspci' is a synonym for 'cat /proc/pci'. By altering files located in this directory you can even read/change kernel parameters (sysctl) while the system is running.

The most distinctive thing about files in this directory is the fact that all of them have a file size of 0, with the exception of kcore, mtrr and self.

[jncl]

Hi Cyclic,

  Rather than backup proc/sys/fs/inotify/max_user_watches,  I added the following lines to /opt/bootlocal.sh

Code: [Select]

# change max_user_watches value to 10000 (for minidlna)
echo 10000 > /proc/sys/fs/inotify/max_user_watches

HTH

  Jon

[Cyclic]

Hi Greg: No I wasn't getting the "Done" message, I checked /tmp/backup_status as advised and it also alerted me to the fact that one of the files I was trying to backup didn't exist, so I've corrected that - and I do get the "done" message now.  Thank you, I didn't know which file to check and now I do so I've learnt something new.

Hi Rich: You're right, I've saved that link for later ingestion as it looks like there's a lot of essential linux background on that site which I should probably read before pestering you lot with basic questions.

Hi Jon: I've taken your advice on that and yes that does help, it's an excellent solution so thank you kindly.  I upped the max_user_watches to 524288 which I gather is the maximum you can set.  Allegedly inotify will only use what it needs but I'll keep an eye on it and post here if it causes any issues.

It occurs to me that I have a lot of reading to do,  I started reading "Into The Core" yesterday and now Rich has given me that link I think I'm going to be busy.  I did used to admin an old Unix motorola (you know with a green CRT) but that was 20 years ago so I'm rusty on the linux side.  I remember it would crash if the processor got over 75 degrees C so there'd be chaos when the air-con failed, which was far too often.

Thank you to all for your help.

Best,

Cyclic