Life

OwnCloud Camera Import Sort Script 1 2 3 4 5 6 7 8 9 10 11 12 BASE_DIR=/var/www/owncloud.heimdaheim.de/data/christian/files/Camera-Import SORT_DIR=/var/www/owncloud.heimdaheim.de/data/christian/files/Camera-Sorted find "$BASE_DIR" -type f -name "*" | while IFS= read -r file; do year="$(date -d "$(stat -c %y "$file")" +%Y)" month="$(date -d "$(stat -c %y "$file")" +%b)" filestamp="$(date -d "$(stat -c %y "$file")" +%Y%m%d)" [[ ! -d "$SORT_DIR/$year/$month" ]] && mkdir -p "$SORT_DIR/$year/$month" mv "$file" "$SORT_DIR/$year/$month/${filestamp}_${file##*/}" done Description This Bash script automatically sorts camera uploads from OwnCloud into a year/month directory structure. Files are organized based on their modification date and prefixed with a timestamp in the filename. ...

This is how to sort files into date separated folders. 1 2 3 4 5 6 7 8 9 10 BASE_DIR=/var/www/owncloud.heimdaheim.de/data/christian/files/oldgallery SORT_DIR=/var/www/owncloud.heimdaheim.de/data/christian/files/datedgallery find "$BASE_DIR" -type f -name "*" | while IFS= read -r file; do year="$(date -d "$(stat -c %y "$file")" +%Y)" month="$(date -d "$(stat -c %y "$file")" +%b)" filestamp="$( date -d "$( stat -c %y "$file")" +%Y%m%d)" [[ ! -d "$SORT_DIR/$year/$month" ]] && mkdir -p "$SORT_DIR/$year/$month"; mv "$file" "$SORT_DIR/$year/$month/${filestamp}_${file##*/}" done

So I just had the issue, that I encountered a long running local tracking git repo to be huge. And it wasn’t that there are huge (lfs) files stored in it. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 # du -h --max-depth=1 --exclude=.git /var/www/pma.heimdaheim.de/www/ 60K /var/www/pma.heimdaheim.de/www/.github 676K /var/www/pma.heimdaheim.de/www/doc 20K /var/www/pma.heimdaheim.de/www/examples 9.0M /var/www/pma.heimdaheim.de/www/js 5.8M /var/www/pma.heimdaheim.de/www/libraries 59M /var/www/pma.heimdaheim.de/www/po 92K /var/www/pma.heimdaheim.de/www/scripts 28K /var/www/pma.heimdaheim.de/www/setup 28K /var/www/pma.heimdaheim.de/www/sql 1.5M /var/www/pma.heimdaheim.de/www/templates 3.3M /var/www/pma.heimdaheim.de/www/test 9.0M /var/www/pma.heimdaheim.de/www/themes 20M /var/www/pma.heimdaheim.de/www/vendor 92M /var/www/pma.heimdaheim.de/www/node_modules 28K /var/www/pma.heimdaheim.de/www/tmp 200M /var/www/pma.heimdaheim.de/www/ Now after looking at that, we can take a closer look into the git-directory itself (as to what is consuming the space): ...

This is a quick note for some commands, I have found useful. Get the currently configured OS hostname 1 > racadm get System.ServerOS.Hostname Set the configured OS hostname 1 2 3 > racadm set System.ServerOS.Hostname hv-2.ka.beiheimdaheim.de [Key=System.Embedded.1#ServerOS.1] Object value modified successfully Reset the SSL certificate 1 2 > racadm sslresetcfg > racadm racreset https://mindlesstux.com/2018/03/13/idrac-7-letsencrypt-wildcard-cert/ https://www.itechlounge.net/2018/03/dell-how-to-install-a-custom-issued-ssl-certificate-on-idrac/ Get a list of all storage devices, and their blocksize (conversion of NetApp Disks - blocksize 520) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 $ for sg in $( ls /dev/sg* ); do output=$(sg\_format $sg 2>/dev/null); blocksize=$( echo "$output" \| grep 'Block size' \| cut -d\\= -f2 \| cut -d\ -f1); echo "$sg: $blocksize"; done /dev/sg0: 512 /dev/sg1: 512 /dev/sg10: 512 /dev/sg11: 512 /dev/sg12: 512 /dev/sg13: 512 /dev/sg14: 512 /dev/sg15: 512 /dev/sg16: 512 /dev/sg17: 512 /dev/sg18: 512 /dev/sg19: 512 /dev/sg2: 512 /dev/sg20: 512 /dev/sg21: 512 /dev/sg22: /dev/sg23: /dev/sg3: 512 /dev/sg4: 512 /dev/sg5: 512 /dev/sg6: 512 /dev/sg7: 512 /dev/sg8: 512 /dev/sg9: 512 List the servers power status and try and turn the power off. 1 2 3 4 admin1-> racadm serveraction powerstatus Server power status: ON admin1-> racadm serveraction powerdown ERROR: Timeout while waiting for server to perform requested power action. If you happen to have 3rd party fans inside the system, you may get the above reaction. ...

Since I got the pleasure of watching some Windows boxen with Nagios, I took the Windows Update plugin from Michal Jankowski and implemented it. It took me some time, to initially set up the nsclient++ correctly so it just works, but up till now the check plugin sometimes reported the usual “Service Check Timed Out”. Usually I ended up increasing the cscript timeout, or the nsclient++ socket timeout, but it still kept showing up. Since I rely heavily on my surveillance tools, I have the demand, that as few as possible false positives show up. So I ended up chasing down this error today, and after that I have to say it was quite simple. ...

I was fighting with our VTL again, and TSM was thinking all the drives were offline. In order to update the drive status, you’d need to go into the ISC and select each drive and set them to ONLINE. Since I’m a bit click-lazy, I wrote a simple nested for-loop, which gives me the output to update all the drives at once: 1 2 3 4 5 for i in 1 2; do for k in $( seq -w 1 32 ); do echo "UPDATE DRIVE VTL$i VTL${i}_DR${k} ONLINE=YES" done done Result is a list like this: ...

I had this weird plugin error the other day which bothered me on Friday. I decided to go fixing it. So after poking around in the vCenter installed software list. I couldn’t find the Auto Deploy in the list, so I figured due to my recent vCenter reinstallation while keeping the database, I forgot to reinstall Auto Deploy. I went ahead and started the Auto Deploy setup from the DVD again, until I received this weird looking error. Apparently the setup thought (and decided correctly) that Auto Deploy was already installed in my vCenter. ...

Well, I recently prepared a bunch of Debian KVM guests, and today I got annoyed (basically because logwatch complains about it …) by this pesky error message on each startup. What causes this is error is really simple. Udev loads the PC speaker driver (pcspkr) and then (for whatever reason) tries to load the alsa-module for the PC speaker (snd_pcsp). And the second one, basically fails. All we need to do, is create a blacklist.conf and add the latter one to it. ...

Well, the title pretty much says what I want to do. Even if the DS213+ is on top of a living room cupboard, it’s still way to bright .. as I don’t need really need the LED, here’s a quick hack (the ID and the device is taken from the Synology Wiki) on how to disable it on each startup: 1 2 3 4 5 6 7 8 #!/bin/sh case $1 in start) echo "Disabling Power LED" echo 6 > /dev/ttyS1 ;; esac Just place the file in /opt/etc/init.d/S01leds and the script is gonna turn the LED off during a boot/reboot.

As I wrote before about enabling multipathing for the AutoYaST installation it’s about time I write this one here. Sadly AutoYaST needs a little push in the right direction (as to where to actually put the root device), so here’s part of my AutoYaST profile for such a Cisco blade: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 <profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns"> <bootloader> <device_map config:type="list"> <device_map_entry> <firmware>hd0</firmware> <linux>/dev/sda</linux> </device_map_entry> </device_map> </bootloader> <partitioning config:type="list"> <drive> <device>/dev/sda</device> </drive> </partitioning> <scripts> <pre-scripts config:type="list"> <script> <debug config:type="boolean">false</debug> <feedback config:type="boolean">false</feedback> <filename>config-ucs.sh</filename> <interpreter>shell</interpreter> <source><![CDATA[ cat /tmp/profile/autoinst.xml | sed "s,/dev/sda,/dev/mapper/`/sbin/multipath -ll | grep dm-0 | cut -d -f1`," > /tmp/profile/modified.xml ]]> </source> </script> </pre-scripts> <chroot-scripts config:type="list"> <script> <chrooted config:type="boolean">true</chrooted> <debug config:type="boolean">true</debug> <feedback config:type="boolean">true</feedback> <filename>config-ucs-chroot.sh</filename> <interpreter>shell</interpreter> <location>http://install.home.barfoo.org/autoyast/scripts/config-ucs-chroot.sh</location> </script> </chroot-scripts> </scripts> <software> <packages config:type="list"> <package>multipath-tools</package> </packages> </software> </profile> Now, the profile addition takes care of the placement of the root-device now (simply parses multipath -ll) and adjusts the pulled profile accordingly ( /tmp/profile/modified.xml), which AutoYaST then re-reads. ...