• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: [1]
1  Linux Stuff / General Linux questions / Re: minidlna on Guruplug? on: May 03, 2011, 01:11:36 AM
Minidlna works according to the /etc/minidlna.conf file. You should edit it to your needs.
Take special attention to the following configuration lines :
— media_dir : should point to one or more directories with media files inside.
— db_dir : should point to /var/cache/minidlna instead of the default /tmp/…
— notify_interval : 60 or 120 is better than the default if you don’t want to wait 15min for your DLNA device to find the server!

Restart minidlna after modifying this file.

Yves.
2  Linux Stuff / Linux distributions / Re: Unusable files with Debian on Sheevaplug ! (eSata) on: February 06, 2011, 06:25:42 AM
VERY IMPORTANT !!! EXIM4 SECURITY HOLE

I don't know if anyone is still reading this thread… anyway… the above problem may not at all be a packaging problem, but this ROOTKIT instead:
http://www.reddit.com/r/netsec/comments/en650/details_of_the_root_kit_that_go
http://lists.debian.org/debian-security/2010/12/msg00093.html

Indeed, this attack changes most procps files, and leaves some traces in some exim directories, which I found on my system. I was lucky that no harm was done to my system, thanks to the other protections I have. Still, be carefull and look for unusual content in /var/spool/exim4 for a start.

Yves.
3  Linux Stuff / Linux distributions / Re: Unusable files with Debian on Sheevaplug ! (eSata) on: December 31, 2010, 04:36:58 AM
Thank you very much for your logical and helpful observations.

I picked three random commands (a2p, whatis, xauth); each had no attributes set. This concurs to my previous conclusion/solution. Apart from that, nothing special; I don't usually access this server directly, only via its services.

I think I'll leave it at that, for now. I consider this matter solved (and a Debian packaging bug).

Yves.
4  Linux Stuff / Linux distributions / Re: Unusable files with Debian on Sheevaplug ! (eSata) on: December 30, 2010, 04:39:41 PM
For those having the same problem, googling a bit more gave me this link:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/93320
then this one:
http://forum.ubuntuusers.de/topic/kein-upgrade-fuer-tzdata/#post-1154627
leading to this solution (depends on what actual attributes are set on the files):
Code:
SERVER:~# dpkg -L procps | grep bin/ | while read f; do chattr -ia "$f"; lsattr "$f"; done
------------------- /usr/bin/pgrep
------------------- /usr/bin/watch
------------------- /usr/bin/w.procps
------------------- /usr/bin/skill
------------------- /usr/bin/pwdx
------------------- /usr/bin/top
------------------- /usr/bin/tload
------------------- /usr/bin/slabtop
------------------- /usr/bin/pmap
------------------- /usr/bin/vmstat
------------------- /usr/bin/free
------------------- /usr/bin/uptime
------------------- /sbin/sysctl
------------------- /bin/kill
------------------- /bin/ps
SERVER:~# LANG=C apt-get --reinstall install procps

(Reading database ... 34847 files and directories currently installed.)
Preparing to replace procps 1:3.2.7-11 (using .../procps_1%3a3.2.7-11_armel.deb) ...
Unpacking replacement procps ...
Processing triggers for menu ...
Processing triggers for man-db ...
Setting up procps (1:3.2.7-11) ...
Setting kernel variables (/etc/sysctl.conf)...done.
SERVER:~# free -m
             total       used       free     shared    buffers     cached
Mem:           503        481         22          0        130        202
-/+ buffers/cache:        148        355
Swap:          249          1        248
The point seems to NOT have any attributes set on the upgraded files.
As I did not set the attributes myself, I guess this is a packaging bug for procps, affecting a particular upgrade…

Still, this does not explain where the problem came from in the first place… any idea? Compromised system? Bad luck? Flaky SD card?

Yves.
5  Linux Stuff / Linux distributions / Re: Unusable files with Debian on Sheevaplug ! (eSata) on: December 30, 2010, 04:06:23 PM
Well, I'm perfecting my Debian skills due to this… I searched Google and found about the “debsums” tool. The result was very interesting:
Code:
SERVER:/var/log# debsums | grep -v ' OK$' >/tmp/debsums.log
debsums: no md5sums for at
debsums: no md5sums for binutils
debsums: no md5sums for bzip2
debsums: no md5sums for ed
debsums: no md5sums for g++
debsums: no md5sums for initscripts
debsums: no md5sums for installation-report
debsums: no md5sums for libbz2-1.0
debsums: no md5sums for libdb4.5
debsums: no md5sums for libgdbm3
debsums: no md5sums for liblockfile1
debsums: no md5sums for mawk
debsums: no md5sums for module-init-tools
debsums: no md5sums for netbase
debsums: no md5sums for sysv-rc
debsums: no md5sums for sysvinit
debsums: no md5sums for sysvinit-utils
debsums: no md5sums for update-inetd
I don't know if I should worry about the missing md5sums…
Code:
SERVER:/var/log# cat /tmp/debsums.log
/usr/bin/pgrep                                                            FAILED
/usr/bin/watch                                                            FAILED
/usr/bin/skill                                                            FAILED
/usr/bin/pwdx                                                             FAILED
/usr/bin/top                                                              FAILED
/usr/bin/tload                                                            FAILED
/usr/bin/slabtop                                                          FAILED
/usr/bin/pmap                                                             FAILED
/usr/bin/vmstat                                                           FAILED
/usr/bin/free                                                             FAILED
/usr/bin/uptime                                                           FAILED
/sbin/sysctl                                                              FAILED
/bin/kill                                                                 FAILED
/bin/ps                                                                   FAILED
Googling for all those files' basenames together led me to one single Debian package: procps. Does this ring a bell for anyone? Is there a possibility this would come from a compromised server? Or is this simply a broken install of procps? Should the following command be enough to repair?
Code:
apt-get --reinstall install procps
When I try to execute it, here is the result:
Code:
SERVER:/var/log# LANG=C apt-get --reinstall install procps

(Reading database ... 34837 files and directories currently installed.)
Preparing to replace procps 1:3.2.7-11 (using .../procps_1%3a3.2.7-11_armel.deb) ...
Unpacking replacement procps ...
dpkg: error processing /var/cache/apt/archives/procps_1%3a3.2.7-11_armel.deb (--unpack):
 unable to make backup link of `./usr/bin/pgrep' before installing new version: Operation not permitted
dpkg-deb: subprocess paste killed by signal (Broken pipe)
dpkg: error while cleaning up:
 subprocess post-removal script returned error exit status 1
Processing triggers for menu ...
Processing triggers for man-db ...
Errors were encountered while processing:
 /var/cache/apt/archives/procps_1%3a3.2.7-11_armel.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Thanks for any advice.

Yves.
6  Linux Stuff / Linux distributions / Re: Unusable files with Debian on Sheevaplug ! (eSata) on: December 30, 2010, 03:25:05 PM
Here are all further messages from the kernel log (/var/log/kern.log) related to the SD card:
Code:
Dec 27 00:24:30 SERVER kernel: [   24.241099] mmc0: mvsdio driver initialized, using GPIO 47 for card detection
Dec 27 00:24:30 SERVER kernel: [   24.427266] mmc0: new SD card at address ae40
Dec 27 00:24:30 SERVER kernel: [   24.524911] mmcblk0: mmc0:ae40 SD02G 1.84 GiB
Dec 27 00:24:30 SERVER kernel: [   24.529545]  mmcblk0:
Dec 27 00:24:30 SERVER kernel: [   26.210260] EXT3-fs: INFO: recovery required on readonly filesystem.
Dec 27 00:24:30 SERVER kernel: [   26.216697] EXT3-fs: write access will be enabled during recovery.
Dec 27 00:24:30 SERVER kernel: [   33.357219] kjournald starting.  Commit interval 5 seconds
Dec 27 00:24:30 SERVER kernel: [   33.362783] EXT3-fs: recovery complete.
Dec 27 00:24:30 SERVER kernel: [   33.826782] EXT3-fs: mounted filesystem with ordered data mode.
Dec 27 00:24:30 SERVER kernel: [   39.575903] EXT3 FS on mmcblk0p2, internal journal

This all seems normal. The FS recovery is because I had forgotten to flash the kernel after upgrading it; next reboot was not clean (this is fine now). My problem, however, was already there before the upgrade.

Complete system mounts are:
Code:
/dev/mmcblk0p2 on / type ext3 (rw,relatime,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/mmcblk0p1 on /boot type ext2 (rw,relatime)

Doesn't anyone have any idea on what could be wrong? On how I could diagnose, for a start? I mean: what files, apart from /usr/bin/free, are broken? Maybe dpkg could help? Is it a serious problem? Should I worry for my server…

Please help!

Yves.
7  Linux Stuff / Linux distributions / Unusable files with Debian on Sheevaplug ! (eSata) on: December 29, 2010, 10:49:47 AM
Hello,

I have a strange problem I never had before. I don't usually use Debian, so I'm not sure if it comes from Debian or from the Sheevaplug.

Some files on my filesystem seem to be in bad shape, even though no fsck error seems to be reported in the log. There are these messages, though:
Code:
Dec 27 00:24:30 SERVER kernel: [   22.433383] NAND device: Manufacturer ID: 0xec, Chip ID: 0xdc (Samsung NAND 512MiB 3,3V 8-bit)
Dec 27 00:24:30 SERVER kernel: [   22.442091] Scanning device for bad blocks
Dec 27 00:24:30 SERVER kernel: [   22.492202] Bad eraseblock 1239 at 0x000009ae0000
Dec 27 00:24:30 SERVER kernel: [   22.555544] Bad eraseblock 2820 at 0x000016080000
Dec 27 00:24:30 SERVER kernel: [   22.560304] Bad eraseblock 2821 at 0x0000160a0000
Dec 27 00:24:30 SERVER kernel: [   22.612275] Creating 3 MTD partitions on "orion_nand":
Dec 27 00:24:30 SERVER kernel: [   22.617441] 0x000000000000-0x000000100000 : "u-boot"
Dec 27 00:24:30 SERVER kernel: [   22.623006] 0x000000100000-0x000000500000 : "uImage"
Dec 27 00:24:30 SERVER kernel: [   22.628459] 0x000000500000-0x000020000000 : "root"

This is what happens:
Code:
SERVER:/var/log# free -m
-bash: /usr/bin/free: cannot execute binary file

Some more information:
Code:
SERVER:/var/log# cat /etc/debian_version
5.0.7
SERVER:/var/log# uname -a
Linux SERVER 2.6.32-5-kirkwood #1 Wed Oct 20 12:58:44 UTC 2010 armv5tel GNU/Linux
SERVER:/var/log# df -h
/dev/mmcblk0p2        1,7G  677M  951M  42% /

So:
1/ How can I tell Debian to check every file belonging to a .deb package, and then repair any broken file?
2/ How can I ensure such problem won't occur again?
3/ What is happening?!

Yves.
8  General Category / General Discussion / Re: Moving partially onto the SD from flash? on: October 07, 2010, 08:06:15 AM
Here is something I did involving LVM, that may give you ideas on how to proceed:
http://mandrivausers.org/index.php?/topic/83474-remotely-grow-and-shrink-lvm-partitions-mandriva

The problem you have with moving /var seems similar to the problem I had moving /usr under LVM. In short (if you’re not interested in reading the above link), the steps are:
 — copy the data to the new location,
 — change fstab so that the new device node is mounted instead of the old one,
 — lazy-umount the old location and quickly mount the new one (mount -a), then reboot.

I wrote this on-the-fly and did not test. Make sure you understand and feel confident before trying this.

Yves.
9  Linux Stuff / General Linux questions / Sata Samsung drive in eSata enclosure: spin-down causes I/O error on: September 16, 2010, 08:43:32 AM
Hello,

I installed Debian Lenny on my eSata Sheevaplug, by strictly following Martin Michlmayr's guide. Next, I attached to it a self-powered external eSata enclosure, with a Samsung Sata drive inside.

My problem is that, after some time of disk inactivity (or so it seems), the drive seems to spin-down by itself, or enter a sleep state, or similar; and the OS is obviously unaware of this.
Result: strange I/O errors, with “no such file or directory” errors on read attempts, and file listings full of “?” instead of the usual “rwx”, and so on. Restarting the Sheevaplug does not help. Restarting the Sheevaplug AND the external drive, though, leads to normal behaviour again.

I found a cure to this problem: every hour, CRON runs:
“sdparm --command=start /dev/sda”

I've read that a disk can accept only a finite number of spin-ups/downs, so I later changed crontab to run the command every 10 minutes instead.

___ Now the reason for this post. ___

I'm not very satisfied with the current situation, because:
— I'd rather enable the drive's power-save features, which will help bring down power consumption, and noise, and wear.
— I actually fear that this constant “start” command on the drive may be bad for it.

So is there a better solution?

Yves.
10  Linux Stuff / General Linux questions / Canon iP1700 on the SheevaPlug on: September 15, 2010, 07:32:24 AM
Hi,

I've got a Canon iP1700 printer, previously networed using an EPIA-based server. The latter died (PSU), and I bought a Sheevaplug to replace it.

I was in the process of compiling the Canon iP2200 driver (only available driver to my knowledge) on the Sheevaplug, as I did many times before on x86 PCs, when I realized a few parts of it are provided in binary .so files. Of course, the compilation process tells it is skipping these uncompatible files, which are probably i386-only, and then fails with non-found libraries.

Is there any way I could still use this driver? A kind of x86 implementation on top of arm maybe? For example, would QEmu be usable for this purpose?

Alternately, would someone know of any other driver that works for this printer?

Yves.
11  Linux Stuff / Kernel / Re: Kernel SD root device with/without attached eSATA on: September 15, 2010, 05:12:59 AM
Sorry, I misunderstood.

In that case, I don't know if labels can be used. On the other hand, I already successfully used UUIDs for kernel boot options. It was not for root=, though, but rather for resume=, and not on a plug…

Yves.
12  Hardware and U-Boot firmware / Hardware / Re: Using the LED's as outputs on: September 13, 2010, 12:52:47 AM
I don't know if this will help, or if it is related at all… Here on my shining-new eSata SheevaPlug, I had a problem with files on the eSata (LVM) partition suddenly becoming unreadable, with weird listings (the kind with lots of “?” instead of the usual rwx…). At first, I thought that the partition was corrupted, but a total reboot (both the plug and the external enclosure) brought things back to normal. It happened again, though, with a totally different timing.

A bit of googling led me to believe that maybe this was related to the drive spinning-off, and the SheevaPlug being unaware of this. I setup a crontab, running this every hour:
Code:
sdparm --command=start /dev/sda

The problem disappeared. Maybe this could work over USB, too…

Yves.
13  Linux Stuff / Kernel / Re: Kernel SD root device with/without attached eSATA on: September 13, 2010, 12:30:07 AM
In /etc/fstab, you can reference a partition in three different ways:
— “/dev/sdXX”
— “LABEL=XXXXX”
— “UUID=XXXXXXXXXXXXXXXXXXXXXXXX”

The first way is straight-forward but unreliable. The third way is the most reliable because each UUID is unique, system-independent, and valid until the partition is formatted anew; it is however hard to read/type, and non human-friendly. My preference goes to the second way; you only have to be careful to only choose unique labels across all partitions that could be connected to the system. Example on my plug:
Code:
plug:~# ls -l /dev/disk/by-{label,uuid}/
/dev/disk/by-label/:
total 0
lrwxrwxrwx 1 root root 15 sep 13 08:21 BootPlug -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 15 sep 13 08:21 RootPlug -> ../../mmcblk0p2

/dev/disk/by-uuid/:
total 0
lrwxrwxrwx 1 root root 15 sep 13 08:21 0027220a-0bc9-4d4e-9519-a5d107c36b87 -> ../../mmcblk0p2
lrwxrwxrwx 1 root root 15 sep 13 08:21 7be41792-db5c-439d-bcf8-ef4acfcd4eab -> ../../mmcblk0p1

plug:~# grep ext /etc/fstab
LABEL=RootPlug            /             ext3     relatime,errors=remount-ro        0      1
LABEL=BootPlug            /boot         ext2     defaults                          0      2
Yves.
14  Linux Stuff / Linux distributions / Re: eSATA SheevaPlug supported by Debian now on: September 12, 2010, 07:12:32 AM
Thank you. I'll remember, when I update the kernel next time Smiley (so far, no kernel update; I just installed Debian yesterday)

Yves.
15  Linux Stuff / Linux distributions / Re: eSATA SheevaPlug supported by Debian now on: September 12, 2010, 04:28:02 AM
The eSATA SheevaPlug is supported by the Debian installer and by Debian now.  See http://www.cyrius.com/debian/kirkwood/sheevaplug/install.html for the install guide.

If you're already running Debian on your eSATA SheevaPlug but you installed as a regular SheevaPlug to USB or SD and you'd like to use the eSATA, then make sure you're the latest kernel from Debian squeeze (apt-get update; apt-get dist-upgrade; flash-kernel)
Hello,

I'm new here, and new to the (e-sata) SheevaPlug. I followed the fore-mentionned Debian installation guide (Lenny), but I never ran "flash-kernel". What is this command for? Is it mandatory, or only for newer kernels? Or only for Squeeze?

Yves.
Pages: [1]