Just a note before you do this you should have a sure, guaranteed way into the system such as local, KVMor preferably publickey making bruteforce SSH absolutely impossible since there is no password to bruteforce and even if someone knew the password they wouldn't be able to login except from the local console (presumably you should make sure no one unauthorized has physical access).
1. Edit /etc/ssh/sshd_config
Find the section like this:........
Ijust use "ufraw" and it does the trick perfectly. Now Iwish I could figure out how to batch convert them into .jpg with ImageMagick (it seems support for .raw is not guaranteed or it has to be compiled in).
apt-get install ufraw........
This happened during a RAID array check:
SMART says both drives pass the test, but I'm doing a long test on them and hopefully this is not a hardware error.
Apr 3 04:22:01 remote kernel: md: syncing RAID array md2
Apr 3 04:22:01 remote kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
Apr 3 04:22:01 remote kernel: md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
high IO wait
424 root 39 19 1900 848 552 D 0.0 0.0 0:00.91 updatedb
root 424 0.0 0.0 1900 848 ? DN Mar11 0:00 /usr/bin/updatedb -f sysfs?rootfs?bdev?proc?cpuset?binfmt_misc?debugfs?sockfs?usbfs?pipefs?anon_inodefs?futexfs?tmpfs?inotifyfs?eventp........
I think this will be useful to others because I have a server that kept crashing mysteriously during intense disk usage/RAID checks. It would only crash during the weekly RAID integrity check.
ThenI noticed during a reboot that not all CPUs were being brought up, as a result this actually creates much higher temperatures with the output I got from sensors, just booting the system produced higher than normal temperatures.
You can imagine that a full blown RAID check........
Jan 16 04:02:03 centosbox syslogd 1.4.1: restart.
Jan 16 04:07:34 centosbox kernel: INFO: task updatedb:20771 blocked for more than 300 seconds.
Jan 16 04:07:34 centosbox kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 16 04:07:34 centosbox kernel: updatedb D F78BE050 6476 20771 20766&n........
This made me nervous but it's clearly a cronjob based on the messages log that happens every Sunday at about 4:22.
I actually can't find any evidence of it in cron.d cron.daily but it is there somewhere obviously.
What I don't get is why doesn't this cronjob do a datacheck like Ubuntu's cronscript does? When you unnecessarily rebuild the array you lose your redundancy during that point which makes your data extremely vulnerable.
*Update I did a grep of &q........
This doesn't seem to be widely known (maybe it's in some documentation that none of us read though)but there's an easy way to check the integrity of any mdadm array:
sudo echo check > /sys/block/md0/md/sync_action
-bash: /sys/block/md0/md/sync_action: Permission denied
sudo will never work, this only works as root since echo is not actually a binary/command. It is built-into bash.
Install the "Editors" and "Net" groups that will give you rsync, ssh, ssh-keygen and cron.
The trickiest thing that I keep forgetting about each time is you have to run "cron-config" which adds the cron service to Windows, and without doing that obviously no cron jobs will be run thus making automatic backups impossible.
Warning about rsync/cygwin and using the -a archive switch.
It's a good thing I caught this because it doesn't work ri........
This really made me nervous but notice the mdstat says "check". This is because in Ubuntu there is a scheduled mdadm cronscript that runs everyday on Sunday at 00:57 that checks your entire array. This is a good way because it prevents gradual but unnoticed data corruption which Inever thought of.
As long as the check completes properly you have peace of mind knowing that your data integretiy is assured and that your hard drives are functioning properly (I'........
cat /proc/user_beancounters produces the following:
kmemsize 1861537 5139870 12752512 12752512 26965041
Notice the failcnt "26965041", that is for kmemsize and at first it confused me. The system had enough guaranteed and enough burst RAM available. kmemsize is a variable indepedent of that, but who cars about the explanation right, let's just make thing........