It makes no sense to ask for a password after a user has pressed the suspend button (after all, if they wanted to deny service to other users, they could just as well power off the system while they have physical access).
So I want to disable that password prompt.
The following file placed in /etc/polkit-1/rules.d
allows a user to
suspend the system without needing the user’s password:
1 2 3 4 5 6 |
|
If there is a way to allow the same thing with less permissions (remotely logged in users need not be able to suspend the system, after all), I do not know it. But this scratches my itch, so this concludes my interest in this matter.
(Documented so I can find it again the next time I install a system.)
]]>250g Mehl (hier: Dinkel, frisch gemahlen)
150g weiches Fett (hier: Butter)
1 Ei (vom Huhn, mittelgroß)
0.5TL Salz (hier: genaue Menge ausprobiert)
Zu Teig verkneten, 1h lang im Kühlschrank ruhen lassen. Abschmecken.
Springform aus der ⌀26cm-Klasse einfetten und mit Bröseln bestreuen.
0.5 dünne Stange Lauch
(hier: die Hälfte mit den grünen Blättern)
in schmale Streifen schneiden (hier: ca. 3-5mm breit, 8-30mm lang).
1 Paprika, rot
1 Paprika, gelb
0.5 kleine Zucchini
würfeln (5…10mm Kantenlänge funktionieren hier gut).
TBD: Küchenfachbegriff für die Matrix.
3 Eier (Huhn, mittel)
200g geriebener junger Gouda
(Diese Menge ist SEHR grob geschätzt)
400g saure Sahne (10%ig, 2 Becher à 200g)
40g Stärke
etwas Salz
etwas weißer Pfeffer
Gut glattrühren. Zur Vermeidung von Stärkeklumpen erst einmal die Stärke mit wenig Sahne glattrühren und dann sukzessive flüssiger machen.
Die Springform mit dem Mürbteig auskleiden. (Hier: Stücke weichkneten, auf Arbeitsfläche vorformen/auswellen, in Springform setzen und Fetzen miteinander verbinden.) Man kann je nach persönlichen Vorlieben den Teig auch auf Maß auswellen und in die Springform setzen oder einfach formlos Fetzen für Fetzen mit den Fingern in die Springform drücken.
Matrix mit Gemüse zur Füllung mischen. Durchmischen, bis die Stücke halbwegs homogen in der Matrix verteilt und alle Stücke vom Matrixfluid benetzt sind. Abschmecken. Das Matrix-Fluid alleine darf ruhig etwas zu salzig schmecken, weil die Gemüsestücke selbst ja nicht salzig schmecken.
Die Füllung in die Kuchenform kippen und oben glattstreichen. Mit
100-150g geriebenem jungem Gouda
bestreuen. Vorsicht: Wenn zu viel Käse oben drauf ist und die Kruste oben viel härter gebacken wurde als das Innere der Füllung, lässt sich der Kuchen nur noch schwer sauber aufschneiden.
Den über das Niveau der Füllung hinausreichenden Teil der Mürbteigwand auf die Füllung herunterklappen. (Das vermeidet zwei Probleme: Wenn die Wand über der Füllung stehenbleibt, wird sie evtl. beim Backen zu dunkel und spätestens beim Anschneiden des fertigen Kuchens bröselt sie wild in der Gegend herum.)
Auf Gitter in mittlere Schiene mit Fettpfanne in unterer Schiene (ohne Fettpfanne macht das raustriefende Fett Riesengestank und -sauerei im Ofen). 150-160° Umluft. Wenn der Käse oben nach ca. 40min oben beginnt, braun zu werden, kann auf 130° oder sowas zurückgegangen werden, bis der Kuchen insgesamt 70…90min im Ofen war.
Es soll hier ja nicht nur die Matrix stocken und der Käse oben goldbraun (aber nicht schwarz) werden, sondern auch der Lauch gar werden, d.h. es braucht ein bisschen länger.
Nach dem Backen den Kuchen in der Springform etwas abkühlen lassen. Dann die Springform vorsichtig entfernen. Den Kuchen entweder gleich lauwarm essen oder vollständig abkühlen lassen. Damit die Feuchtigkeit nicht unten den Boden durchweicht, idealerweise den Kuchen beim Abkühlen auch unten ausdampfen lassen, d.h. Kuchen auf Gitter setzen. Ein Kuchenretter ist beim Umsetzen hilfreich.
Das Abkühlen auf Raumtemperatur und das Ausdampfen dauern mehrere Stunden. Wenn es schneller gehen muss, hilft ein Ventilator (dann nur noch ca. 1h, dabei auf guten Luftstrom ober- wie unterhalb des Kuchens achten).
Viel Vergnügen.
]]>The headset has a 3.5mm TRRS plug where the tip, ring, ring, and sleeve are left headphone, right headphone, ground, and microphone, respectively.
The mixer is unlike almost any other mixer in that it has two 3.5mm TRS jacks for headphone out and microphone in just like a PC soundcard has. The headphone out tip, ring, and sleeve are left headphone, right headphone, and ground, respectively. The microphone TRS connector tip, ring and sleeve are microphone signal input, microphone bias voltage output, and ground, respectively.
The schematic for a headset adapter connecting the headset’s TRRS plug to the two PC TRS jacks looks as follows:
This makes the complete schematic (consisting of headset headphones, headset cable with microphone and pusbutton, the headset adapter to be built, and the PC soundcard or mixer) look as follows (omitting unnecessary details):
A quick remark about the pushbutton on the headset’s microphone: This pushbutton shorts the microphone line to ground. This both shorts any AC signal from the microphone and also any power transmitted to the microphone in the form of the DC bias voltage. Both have the effect of muting the microphone while the pushbutton is being kept pushed down.
Back to the adapter.
I wanted to hide the adapter circuit inside a block of wood, so just soldering a few wires, heatshrink wrapping them and putting them into a hole drilled for that purpose was the obvious idea:
However, I had run out of heatshrink tubing, so I had to find another way to keep blank contact surfaces from touching: I cut a 3x3 piece from the corner of a piece of perfboard to make the connections:
Actually, I put the headphone cable in a layer below and between the microphone cable and the electrolytic cap, so the whole circuit fits into a 12mm diameter hole drilled about 6cm deep:
(Photographs to follow)
]]>First, we tell cron to start the session after every reboot (update 2015-03-22: this does not always work, see bottom of this post for potential remedy).
1
|
|
The actual starting of the session is done with a shell script which calles tmux a few times.
1 2 3 4 5 6 7 8 9 10 11 12 |
|
And we make tmux look and feel a bit more like screen.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
Now, when I log into the shell host, I attach to my tmux session as follows
1 2 |
|
That’s it. For the most part.
If the @reboot
in the crontab
fails, it might be because some
things on the system need more time to come up properly after booting
(e.g. filesystems). In that case, starting the tmux session later
might help, as in the following crontab snippet:
1
|
|
This works better for me than immediately starting the
.start-tmux-auto
script, which often failed to start a tmux session.
For camera noise details at ISO 2500 at original resolution, zoom into the following image:
]]>Cut
1 onion, not quite tennis ball sized
into small dice and mix those with
some vinegar and
some salt
and let it sit for an hour or more. About 10..15ml of vinegar and half a tablespoon of salt can work out well. Vary to your own taste.
In the mean time, you can do other things and then continue with the salad.
Start with most of
500g yoghurt
in a large bowl and add most of the onions (without much vinegar, we may need the vinegar later).
Then cut the vegetables into small pieces (radish and carrot pieces should be very small) and stir them into the yoghurt:
2 bell pepper, red (Paprika, rot)
2 bell pepper, yellow (Paprika, gelb)
1 bell pepper, green (Paprika, grün)
1 kohlrabi (Kohlrabi)
1 broccoli (Broccoli)
6..10 tomatoes, ping pong ball sized (Tomaten in Tischtennisballgröße)
or comparable quantity (bzw. vergleichbare Menge)
5 radishes ([Radieschen](https://de.wikipedia.org/wiki/Radieschen))
1 carrot (Möhre)
The radish pieces should be a bit smaller than the others in order to more evenly distribute their aroma and hotness.
The carrot pieces should be much smaller than the others as carrots have a much firmer texture.
Adjust the amount of sauce by adding more yoghurt and/or tomatos. The sauce is supposed to mostly cover the pieces so they can exchange some taste with the sauce and each other.
Adjust the hotness by adding more radish pieces.
Adjust the taste by adding
some salt
some salad oil (rape seed oil works nicely)
some chili powder (Paprikapulver, scharf)
the remaining vinegar
the remaining onions
Let the salad sit for a bit to let substance concentrations even out some, then re-adjust the taste. Stir early, stir and re-adjust taste often.
Some ideas for variations:
Enjoy.
]]>To recap that previous post, I triggered one of the LEDs on my WRAP as a YUP LED with ICMP echo reply packets, which results in blinking patterns which let me read which other hosts are switched on. The ICMP echo replies arrive as replies to the packets sent by a bunch of ping processes.
Now I have written a new program send-echo-request to make the blinking pattern timing more precise and above all to avoid the race conditions caused by the two ping processes running in parallel.
Every 0.5s, send-echo-request
sends an ICMP echo request to the two
hosts which interest me, and the iptables rules then triggers the LED
with a very short 0.1s flash for a reply from one host, and a much
longer 0.4s one from the other host.
As the hosts on my local LAN reply within much less than 0.01s, the
echo replies arrive practically in the same 0.5s pulse
send-echo-request
sends the echo requests in.
Here are the installation and setup steps in short:
1 2 3 4 |
|
1 2 3 4 5 6 7 |
|
1 2 3 4 5 6 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
/etc/init.d/aiccu
start script in order not to violate the
SixXS terms of service regarding repeated and
unattended tunnel setup.
However, I want to have the router try one tunnel setup after I have manually switched it on.
Now, in order to have aiccu successfully set up a tunnel, we will have to ensure a set of conditions is met when we run `aiccu start´.
tic.sixxs.net
In my case, I can reasonably guesstimate the IPv4 connectivity by the presence of a default route.
However, guessing wether the system time is accurate on a system without an RTC is not that trivial - at first glance.
Fortunately, the NTP daemon which comes with OpenWRT can run a program
when it receives a time update, so we can change its init script to
add -S /etc/ntp-hook
to the ntpd arguments.
1 2 3 4 5 6 7 8 9 |
|
The hook just writes the current time into a file /tmp/date
which
does not exist on bootup. So the presence of /tmp/date
indicates the
ntp-hook
has run at least once, which means that we have a proper
system time.
1 2 3 |
|
Note that we need to be careful to start aiccu
from rc.local
in
the background, so that the init startup process can continue.
1 2 3 4 5 |
|
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 |
|
So I set up a SixXS IPv6 tunnel endpoint on the WRAP, and while reading the OpenWRT documentation, I stumbled over the mentioning of LEDs. Turns out that OpenWRT can trigger some boards’ LEDs on a number of events - which let me configure two special purpose LEDs instead of the two unused-by-default in the WRAP’s array of 3 GPIO LEDs.
The first LED shows me the basic system state: power is on and system is booting, system has booted, system has shut down.
The second LED shows me “Link Status” and TX/RX activity on the IPv6 tunnel endpoint. Just like the LEDs commonly found on Ethernet RJ45 jacks do, but for a software defined virtual network interface.
The third LED shows me whether someone else in the local network has their computer turned on. For me, this means that I know to avoid saturating the internet uplink while someone else might be trying to use the internet.
1 2 3 4 5 6 |
|
Manually playing with the pseudo files in /sys/class/leds/*/
showed
that we can actually control the LEDs through this interface.
OpenWRT is set up such that /etc/config/system
can contain config
led
sections which are read and applied close to the end of the
system boot.
When the WRAP board is supplied with electricity, the power LED turns on and stays on.
However, I would rather the LED showed me more than just the presence of power:
When the system is being rebooted or halted, it would be nice to see when the system has actually finished shutting down.
When the system is booting, it would be nice to see when it has finished booting.
When the system is turned on, the WRAP firmware turns on the power LED
and keeps it on. Then OpenWRT runs through all /etc/rc.d/S*
scripts
in order. When it arrives at S99led
, the following configuration is
activated, making the power LED flash for 0.1s every second.
1 2 |
|
1 2 3 4 5 6 7 |
|
For the shutdown, we need to put some code late into the sequence of
/etc/rc.d/S*
scripts being run.
1 2 3 4 5 6 7 8 9 |
|
1 2 |
|
That’s it.
The following lights up the middle LED when the sixxs0
tunnel
endpoint network interface becomes available and has a ‘link’, and
flashes the LED dark whenever a data packet goes through the sixxs0
interface.
1 2 |
|
1 2 3 4 5 6 7 8 9 |
|
If we had three whole LEDs to spare, we could spend one LED on the link status, the second one flashing on transmission and the third one flashing on reception of a data packet.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
Or if we have two LEDs to spare, we could do
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
Update: I have put a much improved version of this setup at YUP LED With Send-echo-request.
In case someone else is busy with their PCs on my home network and I am downloading something, they will want to signal me to yield at least some of the uplink to them.
OpenWRT makes it easy to dedicate a LED to YUP
(yield uplink,
please) at the cost of running one or more continuous ping processes
on the OpenWRT system and having the respective ICMP packets on the
LAN.
1 2 3 4 |
|
1 2 3 4 5 6 7 |
|
1 2 3 4 5 6 7 8 |
|
1 2 3 4 5 6 7 |
|
This can even be changed to have a secondary function of showing that
another host 192.168.1.23
is up while primary host 192.168.1.42
is
down:
1 2 3 4 5 6 7 8 9 10 |
|
EXT4-fs (sdg4): bad block size 65536
?
This article summarizes what I had to find out while I was in that situation.
The Linux kernel driver for the ext4
filesystem only handles
filesystems with a block size between 512 and PAGE_SIZE
. On the
common PC architectures x86_64 (64bit) and i386 (32bit), PAGE_SIZE
is 4096 (4K). The filesystem on the WD MyBook Live hard disk has a
block size of 65536 (64K), though, suggesting the WD MyBook Live comes
with a CPU with a PAGE_SIZE
of 65536.
So we cannot use the Linux kernel driver to read that ext4
filesystem on a normal PC/laptop.
Fortunately however, the userspace implementation
libext2fs
(used by
debugfs(8)
) is not limited by the kernel’s PAGE_SIZE
and can
therefore read the filesystem.
Update 2016-09-10: Chris Turchin suggests an even cooler approach: using the fuse driver for ext3
which allows mounting the filesystem like you mount any normal
filesystem. I have not tried this fuse based approach, but the idea
sounds quite promising and I will definitely follow up on it when I next find
myself confronted with a 64K block size ext4 filesystem on a system
with a smaller PAGE_SIZE
. The following text still describes the
steps I followed in 2012 to read the data off the disk using
debugfs(8)
/libext2fs
.
Tools to extract the disk from the NAS enclosure
PC/laptop running a reasonably recent version of Linux (GPT support required)
A way to attach the disk from the NAS enclosure to that PC/laptop (e.g. SATA cable, USB enclosure + USB cable, etc.)
Sufficient amount of free storage space on the PC/laptop to hold a copy of all data from the NAS disk. Caution: This might amount to several TB.
Extract the disk from the NAS enclosure and connect it to your PC/laptop.
Create a new empty directory mkdir /path/to/saved-stuff
on the
free storage space where you will store the copy of the rescued
data.
Run debugfs /dev/sdg4
(your device name will vary).
Inside debugfs(8)
, run the ls
command to verify that you can
see the shares
directory. You can also look into the shares
directory with the ls shares
command.
Inside debugfs(8)
, run the rdump
command as follows: rdump
shares /path/to/saved-stuff
. This will copy all the data from the
shares
directory on the disk from the NAS to your local free
space as /path/to/saved-stuff/shares/
.
Wait until the copying has finished. This will take many many hours if you have a lot of data to transfer, especially if you have the disk connected via USB 2.0.
sfdisk -l
shows the primary partitions as if they were actual
device names. As the disk uses GPT, these partition names have
nothing in common with the actual device names.
According to the kernel sources, a PAGE_SIZE
of 65536 is
supported by the following architectures: ia64, mips, parisc,
powerpc, sh, sparc. So you might also be successful running a
mips64 Linux distribution inside qemu-mips
and mounting the
filesystem.
After unsoldering the sheetmetal shielding cage on the MyBook Live sytem board, I can identify the SOC to be an Applied Micro APM82181 (APM82181 product details). This appears to be a PowerPC based chip specifically designed for NAS applications.