Beiträge von Greywolf

Zitat

Original von ggsm
in mail.log steht folgendes:

Code

Jan 25 16:22:33 vXYZ postfix/master[29476]: daemon started
Jan 25 16:22:54 vXYZ postfix/smtpd[2661]: connect from XYZ.dip.t-dialin.net[84.160.111.2]
Jan 25 16:22:55 vXYZ postfix/smtpd[2661]: warning: XYZ.dip.t-dialin.net[84.160.111.2]: SASL CRAM-MD5 authentication failed

Welche Passwortdatenbank nutzt SASL?
Wenn sasldb: ist der Benutzer dort (mit dem richtigen Realm) eingetragen?
Falls mit einem Plugin auf die passwd/shadow zurückgegriffen wird, dann geht CRAM-MD5 nicht, nur PLAIN/LOGIN.

Zitat

2) ich würde gerne das empfangen von ein paar Dateien verhindern
(*.exe, *.pif, *.com, ...)

also hab ich folgendes in die main.cf eingetragen:
mime_header_checks = regexp:/usr/antispam/mime_header_checks.regexp

in der Datei /usr/antispam/mime_header_checks.regexp steht folgendes:

Code

/name=[^>]*\.(bat|chm|cmd|com|do|exe|hta|jse|rm|scr|pif|vbe|vbs|vxd|xl)/
  REJECT  Rule #666 We do not like Windows executables for security reason. Please do not send us executables. Thank you.

leider passiert genau gar nichts.

Alles anzeigen

Probiers mal mit diesem PCRE Ausdruck (2. Beitrag von Noel Jones).
Vielleicht ist der Dateiname kodiert (quoted-printable und base64 werden von mime_header_checks wohl nicht aufgelöst) oder der Ausdruck einfach fehlerhaft.

Läuft rpc.statd auf Client und Server?

Zitat

Original von purzel
Wem dass nicht reicht, kann die Dateiattribute noch mit chattr verbiegen, damit bekommt man z.B. Dateien sogar vor root geschützt (löschen und verändern): chattr +i DATEINAME

Ja, chattr bietet laut man page zwar diverse Spielereien ... aber das Dateisystem muss dabei auch mitspielen.

Läuft es bei Dir? Habe es eben nach langer Zeit nochmal wieder probiert, aber mit reiserfs und tmpfs (Kernel 2.6.14) bekomme ich nur "Inappropriate ioctl for device" ... "falsche" Dateisysteme oder nur eine Kerneloption vergessen?

Zitat

Original von devnix

Also so ist es falsch. Wie ich oben bereits beschrieben habe: Bearbeiten darf man trotz "+t" auch fremde Dateien, sofern man Schreibrechte für die Datei hat. Dazu zählt auch, den kompletten Inhalt einer Datei zu löschen. Die Datei selber (genauer: den Verzeichniseintrag, man denke an Hardlinks) darf hingegen nur der Besitzer löschen.

root@matrix:/tmp# echo bla > x
root@matrix:/tmp# cat x
bla
root@matrix:/tmp# chmod 666 x
root@matrix:/tmp# su greywolf
greywolf@matrix:/tmp$ echo blub >> x
greywolf@matrix:/tmp$ cat x
bla
blub
greywolf@matrix:/tmp$ rm x
rm: cannot remove `x': Operation not permitted
greywolf@matrix:/tmp$ ll -d . x
drwxrwxrwt  6 root root 220 2006-01-11 17:44 ./
-rw-rw-rw-  1 root root   9 2006-01-11 17:46 x

Zitat

Original von hjs
In dem Moment , wo du jemandem das Recht gibst , eine Datei zu beschreiben , kann er sie auch löschen - er könnte sie ja auch komplett überschreiben .

Nicht ganz: um Dateien zu Löschen braucht man Schreibrechte für das Verzeichnis. Wenn man dem Nutzer diese nimmt, dann kann er natürlich auch keine neuen Dateien mehr erstellen ...

Alternativ könnte man es machen wie bei /tmp. Also chown root:root [directory] und chmod 1777 [directory]. Dann kann man neue Dateien anlegen und bestehende Dateien bearbeiten (Schreibrechte an der Datei vorausgesetzt, also entweder "g+w" oder "o+w"), aber nur eigene Dateien löschen.

Zitat

Original von Brougs78
Du musst vor dem Start von VDR LC_ALL oder LANG exportieren (LANG hatte bei mir nicht immer funktioniert)

Auf LANG wird nur zurückgegriffen, wenn LC_(COLLATE|CTYPE|MONETARY|MESSAGES|NUMERIC|TIME|...) nicht gesetzt ist. LC_ALL hingegen überschreibt alles. Siehe man 7 locale.

Mit locale kann man sehen, welche Werte (explizit oder implizit) wie gesetzt sind (natürlich nur auf die aktuelle Shell bezogen).

Generell alle Zugriffe oder für einzelne Dateien/Verzeichnisse?

Für letzteres gibt's inotify

Zitat

Original von geronimo
die Kerneloptionen für nfs sind doch alle unter filesystems/net?

Jup, stehen alle untereinander.

Zitat

Ich habe heute erst den kernel für die Testmaschine neu gebaut und die nfs-Optionen waren alle aktiv.

NFSv4 (in Kernel 2.6.14 eh noch als "experimentell" gekennzeichnet) habe ich noch nie ausprobiert, vielleicht kann das zu "Komplikationen" führen?
Wenn NFSv3 nicht "will", obwohl beide Seiten es können sollten, dann würde ich mal NFSv4 komplett deaktivieren.

Bei mir sieht's auf Client und Server so aus:

greywolf@matrix:/usr/src/linux$ grep NFS .config
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
# CONFIG_NFSD_TCP is not set
CONFIG_NFS_COMMON=y

dazu nfs-utils 1.0.7 ... bis 4,5 GB keine Probleme Mehr habe ich noch nicht getestet. (Kernel ist selber kompiliert, nfs-utils sind Original slackware-current)

Auch für den Client-Support gibt's eine Kerneloption für NFSv3 bzw. NFSv4, die sich übrigens unabhängig vom Server-Support setzen lässt.

Die "defaults" lassen sich AFAIK nicht ändern, Anpassungen müssen also wohl für jeden exports- bzw. fstab-Eintrag einzeln vorgenommen werden.

NFSv3 reicht für >2GB, NFSv2 kann es noch nicht. Hat die Testmaschine vielleicht NUR NFSv4 (+NFSv2) und der Server NUR NFSv3 (+NFSv2), so dass auf NFSv2 zurückgegriffen wird?

Zitat

Original von dmh
Könnte man growisofs sowas nicht im Vorhinein sagen?

Zitat

http://fy.chalmers.se/~appro/linux/DVD+RW/#booktype
It's naturally not possible to manipulate the "Book Type" field on DVD+R media, that is not after the lead-in is written [which takes place at the moment the first session gets closed]. But it might be possible to control how it [lead-in] is going to be branded by programming the drive in advance:

dvd+rw-booktype -dvd-rom -unit+r /dev/scdN

... schon probiert?

Zitat

Original von dmh
Weder google noch die Forumssuche brachte mir Hinweise!

Wie wär's mit 'ner Suche in der Doku der dvd+rw-tools (zu denen dvd+rw-mediainfo gehört)?

http://fy.chalmers.se/~appro/linux/DVD+RW/#booktype

Zum Beispiel so:

greywolf@matrix:~$ echo xyz-abc.h | sed -e 's:.*-::' -e 's:\..*::'
abc

oder so:

greywolf@matrix:~$ echo xyz-abc.h | sed -e 's:.*-\(.*\)\..*:\1:'
abc

oder ganz anders:

greywolf@matrix:~$ echo xyz-abc.h | cut -d- -f2 | cut -d. -f1
abc

Zitat

Original von Hulk
Ich bin mir nicht sicher ob es legitim ist einfach per grep die Zeile die mit "D" beginnen zu verwenden, da daduch Zeilen mit Zeilenumbrüchen verloren gehen könnten.

Siehe man 5 vdr ... Zeilenumbrüche innerhalb der Beschreibung werden durch "|" ersetzt, also:

grep ^D info.vdr | cut -d " " -f 2- | tr '|' '\n'

Alles viel zu kompliziert

Einfach im Dateisystem alles so lassen, wie es ist und:

greywolf@matrix:~$ man smb.conf
[..]
       force user (S)
              This  specifies  a  UNIX  user name that will be assigned as the
              default user for all users connecting to this service.  This  is
              useful  for  sharing  files. You should also use it carefully as
              using it incorrectly can cause security problems.


              This user name only gets used once a connection is  established.
              Thus  clients still need to connect as a valid user and supply a
              valid password. Once connected, all file operations will be per-
              formed  as the "forced user", no matter what username the client
              connected as. This can be very useful.


              In Samba 2.0.5 and above this parameter also causes the  primary
              group of the forced user to be used as the primary group for all
              file activity. Prior to 2.0.5 the primary group was left as  the
              primary group of the connecting user (this was a bug).


              Default: force user =


              Example: force user = auser
[..]

"force group" gibt's übrigens auch ...

Wie oben beschrieben sollte man aus Sicherheitsgründen dann dafür sorgen, dass nur vertrauenswürdige User ("valid users") bzw. Rechner ("hosts allow") auf die Freigabe zugreifen können.

Scheinen beides MIDI-"Varianten" zu sein, eine Umwandlung von MP3/WAV/... wird dann nicht möglich sein.

Du wirst wohl zumindest MIDI-Dateien deiner Klingeltöne finden müssen und kannst dann ja mal davon die Demoversion probieren:
http://www.audioutilities.com/…idi-ringtone-composer.htm

(Kenne das Programm nicht, hab's gerade über Google gefunden ... Suche nach "MIDI" und "imelody")

EDIT: Auf derselben Seite gibt's tatsächlich auch ein Link zu einem MP3 nach MIDI Konverter ... aber ob das inzwischen akzeptabel funktioniert bezweifle ich doch etwas ...

Zitat

Original von Herb01

Code

bash> find /wo/auch/immer | xargs touch -c

Besser so:

find /wo/auch/immer -print0 | xargs -0r touch -c

Sonst gibt's Probleme mit Leerstellen.

http://de.wikipedia.org/wiki/Udev

Dynamische Verwaltung von /dev (üblicherweise in einer RAM-Disk), damit dieses nur die tatsächlich vorhandenen Devices enthält.

Für permanente Änderungen muss daher allerdings, wie du ja schon bemerkt hast :D, eine Konfigurationsdatei angepasst werden, weil alle Devices beim Neustart neu erzeugt werden.

Es ermöglicht darüber hinaus auch noch ein paar weitere Spielereien, siehe Wiki. Passend konfiguriert lassen sich auch CD-ROMs automatisch als solche erkennen und der Gruppe "cdrom" zuordnen.

Zitat

Original von magicamun
5. Das device /dev/hdb gehört nach einem Boot immer wieder der Gruppe "disk" - hääää ?

Läuft udev? (Müsste sich mit grep " /dev " /proc/mounts rausfinden lassen) Wenn ja, dann muss in /etc/udev (je nach Distribution) wohl eine Konfigurationsdatei angepasst werden ...

Zitat

Original von magicamun
ich hab seit einiger Zeit den vdr im Kontext des Benutzers vdr am laufen. Dazu hab ich das executeable mit chmod ug+s "bearbeitet" und den Owner vdr:family vergeben, "family" ist meine default-group des vdr.

Dafür ist "+s" nicht "gedacht", damit kann jeder VDR mit den Rechten von vdr:family (und beliebigen Parametern!) starten. Das dürfte auch für die Probleme 2 und 3 sorgen, weil halt wirklich nur diese eine Gruppe (family) gesetzt wird.

Setze das erstmal wieder auf chmod 0755 zurück und dann weiter ...

Zitat

Alle Verzeichnisse/Dateien haben selbstverständlich entsprechende Rechte, damit das so geht. Jetzt gibt es 3 Probleme :

1. /dev/video0 - das hab ich mit einem unschönen chmod og+rw /dev/video0 in der /etc/init.d/vdr hinbekommen

Neue Gruppe "video" anlegen (falls nicht vorhanden), den User vdr hinzufügen und alle Video-Devices root:video mit den Rechten 0660 übertragen.

Zitat

2. /dev/hdb (cdrom) gehört root:disk - vdr hat trotz Mitgliedschaft in der Gruppe "disk" keinen Zugriff !?!?

Weitere Gruppe "cdrom" anlegen (falls nicht vorhanden), hdb an root:cdrom übertragen mit Rechten 0660 und User vdr auch zu dieser Gruppe hinzufügen. Die restlichen hd* gehören sicher auch Gruppe "disk", da sollte vdr keine Rechte drauf haben (-> aus Gruppe "disk" entfernen).

Zitat

"Trick" aus 1 geht nicht - irgendwas biegt nach /etc/init.d/vdr das weider um.

Was wird da "umgebogen"? Die Zugriffsrechte oder die Gruppe zurückgesetzt?

Zitat

3. Die Scripte aus reccmds.conf rennen noch irgendwie als root - das verstehe ich überhaupt nicht - erst nachdem ich in runvdr ein "su - vdr" eingebaut hab, läuft das richtig.

Dürfte mit dem "+s" (s.o.) zusammenhängen. su bzw. sudo ist eh der richtige Weg, um VDR (und auch die meisten anderen Programme) unter einem anderen User zu starten.