Re: Bugreport

View: New views
2 Messages — Rating Filter:   Alert me  

Parent Message unknown Re: Bugreport

by David Haller :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Hallo,

Am Thu, 19 May 2005, Christian Boltz schrieb:

>Am Donnerstag, 19. Mai 2005 05:11 schrieb David Haller:
>> Am Thu, 07 Apr 2005, Christian Boltz schrieb:
>> >    Auch die Frage, ob ACL unterstützt werden, dürfte letztlich nur
>> > mit eine Frage an den User [2] zu klären sein. Trotzdem ein
>> > _Ansatz_ für eine Vorabfrage:
>> >    # df -h ~ | awk '{print $6}'   -> liefert den Mountpoint
>> >    # mount | grep "$ergebnis_von_obigem "   -> liefert die
>> > Mountoption
>>
>> Nein. mount liefert bei mir oefter mal falsche Ausgaben. /proc/mounts
>> ist die richtige Stelle.
>
>/etc readonly gemountet?

Zum Beispiel ;) Ist speziell nervig, wenn man vor dem reboot vergisst
devices zu unmounten, die dann natuerlich nicht in der mtab stehen und
somit dann beim runterfahren nicht unmountet werden... Das fsck nach
dem reboot laesst gruessen. Nachdem mir das ein paarmal passiert ist
verwende fast ich nur noch /proc/mounts.

>> Besser:
>>
>> dev="`df $verzeichnis | awk '{print $1;}'`     # -> liefert device
>> mopt="`awk '$1 == $dev {print $4;}' /proc/mounts`" # -> liefert
>> optionen
>
>Stimmt prinzipiell, allerdings stecken in $dev noch zu viele Angaben:
>
># echo "$dev"
>Dateisystem
>/dev/hda6

Stimmt, das war auch ein Schnellschuss.

dev="`LANG=C df \"$verzeichnis\" | awk 'NR == 2 { print $1; }'`"

>Auch die zweite Zeile will nicht so recht und liefert mir kein Ergebnis.

*GNA* Das hatte ich nicht getestet. $dev ist ja eine Shellvariable und wird
innerhalb der '' nicht expandiert ;) Robust sind wohl folgende Varianten:

    awk -v dev="$dev" '$1 == dev { print $4;}' /proc/mounts
oder
    awk '$1 == "'"$dev"'" {print $4;}' /proc/mounts

$dev muss natuerlich vorher gesetzt sein. Ein einfaches Voranstellen mit
"dev=foo awk ..." reicht nicht (warum auch immer, scheint ein awkism zu
sein)... Bei der zweiten Zeile hilft ein 'set -x' vorher beim Verstehen
des gequot(t)els ;)

>Außerdem funktioniert das Ganze nicht mit verschlüsselten Partitionen -
>man achte jeweils auf /home und den verwendeten Devicenamen:

Ich denke, das gilt wohl fuer alle loop-devices (s.u.).

># df
>Dateisystem          1K-Blöcke   Benutzt Verfügbar Ben% Eingehängt auf
[..]
>/dev/hda6             13938824  11532928   2405896  83% /home
>
>[ BTW: Da meine Laptop-Festplatte etliche Sektoren verloren hat :-( ,

Beileid.

># cat /proc/mounts
[..]
>/dev/loop0 /home ext3 rw,noatime 0 0

># mount
[..]
>/dev/hda6 on /home type ext3
>(rw,noatime,loop=/dev/loop0,encryption=twofish256,acl,user_xattr,commit=600)

Liesse sich wohl durch einen Test auf "/dev/loop*" erkennen. Mich
wundert nur, wieso in der mount-Ausgabe auch noch
'acl,user_xattr,commit=600' auftauchen. Wie sieht die fstab-Zeile dazu
aus?

>> >    # echo $ergebnis_von_mount | grep acl && echo "ACL evtl.
>> > möglich"
>>
>> Das ganze kann man auch in ein awk-script packen:
[..]
>> Da wird zwar immer noch 'df' aufgerufen, aber nur einmal awk ;)
>
>Liefert leider auch nur eine leere Ausgabe für die
>verschlüsselte /home :-(

s.o. das awk sucht nach '/dev/[sh]d*' und in /proc/mounts wird nur
/dev/loop* gelistet... Das liesse sich aber umgehen. Z.B. liefert ja
'losetup "$dev"' die Datei (z.B. das Device) die per loop gemountet
ist. Eine Sonderbehandlung fuer loopdevices waere also kein Problem,
dass man ggfs. 'losetup' befraegt, welche Datei/Device hinter
/dev/loopN steckt ;)

>Für andere Partitionen funktioniert es aber :-)

*g*

>> Im Prinzip braucht man 'df' auch gar nicht, denn das liest auch nur
>> /etc/mtab und /proc/mounts... Vgl. [1].
>
>Ja, aber ich spare mir den ganzen Rattenschwanz des on_which_fs.sh ;-)

Nunja. Wegen mir koennen wir auch mount verwenden, z.B.:

====
open(MNT, "mount|") or die "cannot open pipe from `mount': $!\n";
while(<MNT>) {
    # ...
}
close(MNT);
====

Wobei, einen Test, ob /etc/mtab grad auf einer rw-gemounteten
Partition liegt (und somit "uptodate" sein sollte) koennten wir fuer
mich Paranoiker auch noch einbauen ;)

>> >    Sollte diese Vorabfrage schon negativ ausfallen, brauchen wir
>> > den User erst gar nicht zu nerven.
>> >
>> >[2] Es geht natürlich auch per brute force:
>> >    setfacl -m user:wwwrun:r ~/.fontlinge || echo "ACL not
>> > supported"
>>
>> $ setfacl
>> bash: setfacl: command not found
>>
>> Ein (stummer) Test, ob setfacl existiert, waere Nervenschonend ;)
>
>Habe ich auch so implementiert (&>/dev/null) - allerdings schreibe ich
>im Fehlerfall eine Warnung a la "ACL not supported - please secure
>$configfile yourself" raus.

Gut :)

>Ob das an fehlender Unterstützung von ACL
>im Dateisystem oder schon an der Abwesenheit von setfacl scheitert, ist
>mir dabei übrigens wurst ;-)

Ack.

>> BTW: auch sowas koennte man im Makefile.PL testen.
>
>Prinzipiell schon. Allerdings müsste die Warnung "please secure
>$configfile yourself" trotzdem bei jedem fontlinge_config-Lauf kommen -
>da kann ich es auch direkt in fontlinge_config testen ;-)

Hm. Wird denn auf die normalen Zugriffsrechte getestet?

Jedenfalls: "in perl" sollte das ganze aber auch ohne awk usw.
klappen, und wenn man keine externen Tools wie 'df' und 'mount'
aufrufen muss ist das schneller, d.h. das "on_which_fs" und das
herausfinden der Optionen laesst sich "einfach" in perl
implementieren... Allerdings habe ich mein "on_which_fs.sh" noch nicht
extensiv getestet, mit perls "(l)stat" usw. waere das eh einfacher.
Der Algorithmus sollte aber passen. Und wenn man in perl auch einfach
/proc/mounts lesen kann anstatt 'mount' aufzurufen... ;)

Ich finde, wir sollten das schon im Makefile.PL (vor)behandeln. Ein
Test zur Laufzeit waere aber wohl auch nicht verkehrt.

Und nein, bei den fontlingen macht das sicher nicht viel an der Laufzeit,
aber ich habe mir einfach angewoehnt _immer_ an sowas zu denken. Das macht
die Sache viel einfacher, wenn man dann mal ne Stelle erwischt, wo's dann
relevant auf die Laufzeit durchschlaegt ;)

-dnh

--
>Apropos: wie kann ich auf meiner HP Apollo 425 (HPUX 9.00) PDFs lesen?
Argh, YKINOK! Ja, ist hier denn de.soc.subkultur.bsdm? HPUX, noch dazu 9.00 und
ohne Compiler? Auf einer Kiste ohne CPU und ohne Speicher? Warum nimmst Du denn
nicht gleich einen Abakus? Isst Du auch kleine Kinder mit Senf?   -- KK in dasr


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Fontlinge-devel mailing list
Fontlinge-devel@...
https://lists.sourceforge.net/lists/listinfo/fontlinge-devel

Re: Bugreport

by Christian Boltz :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Hallo David, hallo Leute,

Am Montag, 30. Mai 2005 00:54 schrieb David Haller:
> Am Thu, 19 May 2005, Christian Boltz schrieb:
> >Am Donnerstag, 19. Mai 2005 05:11 schrieb David Haller:
> >> Am Thu, 07 Apr 2005, Christian Boltz schrieb:
[...]
> dev="`LANG=C df \"$verzeichnis\" | awk 'NR == 2 { print $1; }'`"
[...]
>     awk -v dev="$dev" '$1 == dev { print $4;}' /proc/mounts
> oder
>     awk '$1 == "'"$dev"'" {print $4;}' /proc/mounts
[...]
> >Außerdem funktioniert das Ganze nicht mit verschlüsselten
> > Partitionen - man achte jeweils auf /home und den verwendeten
> > Devicenamen:
>
> Ich denke, das gilt wohl fuer alle loop-devices (s.u.).

Vermutlich ja.

> ># df
> >Dateisystem      1K-Blöcke   Benutzt Verfügbar Ben% Eingehängt auf
> [..]
> >/dev/hda6         13938824  11532928   2405896  83% /home
> >
> >[ BTW: Da meine Laptop-Festplatte etliche Sektoren verloren hat :-(
>
> Beileid.

Halb so schlimm - war ein Garantiefall. Nur das Umkopieren der Daten war
eben etwas nervig, da die geliehene USB-Festplatte komplett mit NTFS
formatiert war :-/ und ich, weil wichtige Daten draufwaren,
Formatier-Verbot hatte.

Beim Wegkopieren der Daten sind übrigens nochmal deutlich mehr Sektoren
flöten gegangen -glücklicherweise nur Dateien, die längst im Backup
lagen.

> ># cat /proc/mounts
> [..]
> >/dev/loop0 /home ext3 rw,noatime 0 0
> >
> ># mount
> [..]
> >/dev/hda6 on /home type ext3
> >(rw,noatime,loop=/dev/loop0,encryption=twofish256,acl,user_xattr,com
> >mit=600)
>
> Liesse sich wohl durch einen Test auf "/dev/loop*" erkennen. Mich
> wundert nur, wieso in der mount-Ausgabe auch noch
> 'acl,user_xattr,commit=600' auftauchen. Wie sieht die fstab-Zeile
> dazu aus?

Aus /etc/cryptotab (in der fstab steht die Partition nicht):
/dev/loop0  /dev/hda6  /home  ext3   twofish256 acl,user_xattr,noatime

noatime habe ich irgendwann nach obiger mount-Ausgabe reingenommen, da
micht die atime in /home nicht interessiert (und / ist wegen eines
SuSE-Bugs derzeit extrem lahm oder ebenfalls mit noatime zu mounten -
ich habe mich dann für noatime entschieden ;-)

[...]
> >Liefert leider auch nur eine leere Ausgabe für die
> >verschlüsselte /home :-(
>
> s.o. das awk sucht nach '/dev/[sh]d*' und in /proc/mounts wird nur
> /dev/loop* gelistet... Das liesse sich aber umgehen. Z.B. liefert ja
> 'losetup "$dev"' die Datei (z.B. das Device) die per loop gemountet
> ist. Eine Sonderbehandlung fuer loopdevices waere also kein Problem,
> dass man ggfs. 'losetup' befraegt, welche Datei/Device hinter
> /dev/loopN steckt ;)

Schon klar - aber warum der ganze Aufwand, wenn df die benötigtenn Infos
"frei Haus" liefert?

> >> Im Prinzip braucht man 'df' auch gar nicht, denn das liest auch
> >> nur /etc/mtab und /proc/mounts... Vgl. [1].
> >
> >Ja, aber ich spare mir den ganzen Rattenschwanz des on_which_fs.sh
> > ;-)
>
> Nunja. Wegen mir koennen wir auch mount verwenden, z.B.:
>
> ====
> open(MNT, "mount|") or die "cannot open pipe from `mount': $!\n";
> while(<MNT>) {
>     # ...
> }
> close(MNT);
> ====
>
> Wobei, einen Test, ob /etc/mtab grad auf einer rw-gemounteten
> Partition liegt (und somit "uptodate" sein sollte) koennten wir fuer
> mich Paranoiker auch noch einbauen ;)

*g*

[...]

> >> BTW: auch sowas koennte man im Makefile.PL testen.
> >
> >Prinzipiell schon. Allerdings müsste die Warnung "please secure
> >$configfile yourself" trotzdem bei jedem fontlinge_config-Lauf
> > kommen - da kann ich es auch direkt in fontlinge_config testen ;-)
>
> Hm. Wird denn auf die normalen Zugriffsrechte getestet?
>
> Jedenfalls: "in perl" sollte das ganze aber auch ohne awk usw.
> klappen, und wenn man keine externen Tools wie 'df' und 'mount'
> aufrufen muss ist das schneller, d.h. das "on_which_fs" und das
> herausfinden der Optionen laesst sich "einfach" in perl
> implementieren... Allerdings habe ich mein "on_which_fs.sh" noch
> nicht extensiv getestet, mit perls "(l)stat" usw. waere das eh
> einfacher. Der Algorithmus sollte aber passen. Und wenn man in perl
> auch einfach /proc/mounts lesen kann anstatt 'mount' aufzurufen... ;)
>
> Ich finde, wir sollten das schon im Makefile.PL (vor)behandeln. Ein
> Test zur Laufzeit waere aber wohl auch nicht verkehrt.

... und macht den Test während der Installation irgendwie überflüssig,
IMHO.

> Und nein, bei den fontlingen macht das sicher nicht viel an der
> Laufzeit, aber ich habe mir einfach angewoehnt _immer_ an sowas zu
> denken. Das macht die Sache viel einfacher, wenn man dann mal ne
> Stelle erwischt, wo's dann relevant auf die Laufzeit durchschlaegt ;)

*g*


Gruß

Christian Boltz
--
Einen PC mit 3 GHz-Prozessor, High-End-Grafikkarte und 160 GB Festplatte
brauchen die meisten User genau so sehr wie die meisten Autofahrer einen
PKW mit 250 PS. Und wer das trotzdem haben will, weil er es geil findet,
der finden idR. auch Windows-XP geil - also soll er es haben.
[Matthias Houdek in suse-linux]


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Fontlinge-devel mailing list
Fontlinge-devel@...
https://lists.sourceforge.net/lists/listinfo/fontlinge-devel