Re: ressourcen einschränken
Hi Andreas, On 26.07.2013, at 13:17, Grimnin Fridyson wrote: > --- > > limits.conf: > ... > > twisthardmemlock 2097152 > twistsoftmemlock 1048576 > ## > > ##memlock - max locked-in-memory address space (KB) > --- > > Leider finde ich keine weiteresn Angabe dazu, Die RAM nutzung ist nicht > gleich der "memlock" > kennt jemand eine Berechnungsformel? Die Memlock-Limits sind für den mlock() syscall, um den Adressraum des Programmes im Speicher zu locken und vor Swapping zu schützen. Das hilft dir also nur, wenn dein Programm mlock() nutzt. > > Kennt jemand eine andere Lösung wie man die RAM-Nutzung von Programmen > einschränkt > Was du suchst, dürfte die Direktive as (address space) in der limits.conf sein, die den maximalen Adressraum eines Programmes einschränkt. Hier solltest du allerdings ein paar Bytes für die üblichen Speicherbereiche dazu rechnen (data, bss, gemappte .so's etc.pp). MfG Maddin ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Kein Bild bei X
Hi, X zeigt seit einigen Jahren nur noch ein schwarzes Bild an. Durch den -retro Parameter wird wieder das alte Muster angezeigt und der X-Cursor benutzt, mehr nicht :) Christopher Am Freitag, den 26.07.2013, 21:41 +0200 schrieb Robert Drechsel: > Hallo, > > sehr verzaubernd > # X -retro :1 > und mein X kommt. > > Bei nur: > # X > kriege ich nen dunklen Bildschirm > > sehr verwirrend. > Wie kann ich ihm dann die Einstellungen beibringen? moechte ja per > startx und co auch was sehen.. > > Robert > > ___ > Lug-dd maillist - Lug-dd@mailman.schlittermann.de > https://ssl.schlittermann.de/mailman/listinfo/lug-dd ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Kein Bild bei X
Hallo, sehr verzaubernd # X -retro :1 und mein X kommt. Bei nur: # X kriege ich nen dunklen Bildschirm sehr verwirrend. Wie kann ich ihm dann die Einstellungen beibringen? moechte ja per startx und co auch was sehen.. Robert ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Kein Bild bei X
Da entlädt es nur vesafb, da nouveau selber ein Framebufferdevice bereitstellt. Soweit schaut in den Logs alles gut aus. Hast du ein 2. PC/tablet/smartphone um dich mit den PC zu verbinden? Interessant wäre es zu probieren, über ssh, die Auflösung zu ändern und zu schauen ob ein Bild kommt. Evtl nutzt nouveau ein Monitormode den der Monitor nicht unterstützt (durch ein off-by-one Error oä). Also z.b. ein blankes X starten, idealerweise mit den -retro Parameter: # X -retro :1 und anschließend per SSH: # DISPLAY=:1 xrandr -s 1024x768 Gruß Christopher Am Freitag, den 26.07.2013, 20:55 +0200 schrieb Robert Drechsel: > Hi, > > Xorg.0.log: > http://pastebin.com/AmXFKptZ > > dmesg: > http://pastebin.com/yXzAiuW7 > > > Habe im dmesg was von fb und nouveau vs vesa gesehen.. - verstehen tue > ichs einstellungstechnisch noch nciht > > Robert > > On 26.07.2013 20:43, Christopher Egert wrote: > > Moin, > > > > kannst du bitte dmesg und die xorg.0.log in ein pastebin Service > > kopieren? > > > > Gruß > > > > Christopher > > > > Am Freitag, den 26.07.2013, 13:27 +0200 schrieb Robert Drechsel: > >> Hallo Leute, > >> > >> ich habe gerade das Problem bei einer Neuinstallation eines ArchLinux, > >> dass ich zwar in der Console Bild habe (auch in hoher Aufloesung) nur > >> sobald ich X starte ist der Bildschirm leer. > >> > >> Grafikkarte ist eine: > >> 04:00.0 VGA compatible controller: NVIDIA Corporation G96 [GeForce 9500 > >> GT] (rev a1) (prog-if 00 [VGA controller]) > >>Subsystem: Micro-Star International Co., Ltd. Device 1337 > >>Flags: bus master, fast devsel, latency 0, IRQ 17 > >>Memory at fd00 (32-bit, non-prefetchable) [size=16M] > >>Memory at d000 (64-bit, prefetchable) [size=256M] > >>Memory at fa00 (64-bit, non-prefetchable) [size=32M] > >>I/O ports at ec00 [size=128] > >>Expansion ROM at feb8 [disabled] [size=512K] > >>Capabilities: [60] Power Management version 3 > >>Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ > >>Capabilities: [78] Express Endpoint, MSI 00 > >>Capabilities: [b4] Vendor Specific Information: Len=14 > >>Capabilities: [100] Virtual Channel > >>Capabilities: [128] Power Budgeting > >>Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 > >> > >>Kernel driver in use: nouveau > >>Kernel modules: nouveau > >> > >> > >> > >> Als Grafiktreiber versuche ich einen NOUVEAU zum Laufen zu bekommen. > >> > >> Die Xorg.0.Log gibt keinerlei Fehler aus / wollte die 31k nicht anhaengen. > >> > >> Ich habe gelesen, dass es am GLX liegen koennte, welches geladen wird. > >> die frage waere, wie man es, wenn es dieses sein koennte, abschalten kann. > >> > >> > >> MfG > >> Robert > >> > >> ___ > >> Lug-dd maillist - Lug-dd@mailman.schlittermann.de > >> https://ssl.schlittermann.de/mailman/listinfo/lug-dd > > > > > > > > ___ > > Lug-dd maillist - Lug-dd@mailman.schlittermann.de > > https://ssl.schlittermann.de/mailman/listinfo/lug-dd > > > > > ___ > Lug-dd maillist - Lug-dd@mailman.schlittermann.de > https://ssl.schlittermann.de/mailman/listinfo/lug-dd ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Kein Bild bei X
Hi, Xorg.0.log: http://pastebin.com/AmXFKptZ dmesg: http://pastebin.com/yXzAiuW7 Habe im dmesg was von fb und nouveau vs vesa gesehen.. - verstehen tue ichs einstellungstechnisch noch nciht Robert On 26.07.2013 20:43, Christopher Egert wrote: Moin, kannst du bitte dmesg und die xorg.0.log in ein pastebin Service kopieren? Gruß Christopher Am Freitag, den 26.07.2013, 13:27 +0200 schrieb Robert Drechsel: Hallo Leute, ich habe gerade das Problem bei einer Neuinstallation eines ArchLinux, dass ich zwar in der Console Bild habe (auch in hoher Aufloesung) nur sobald ich X starte ist der Bildschirm leer. Grafikkarte ist eine: 04:00.0 VGA compatible controller: NVIDIA Corporation G96 [GeForce 9500 GT] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. Device 1337 Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at fd00 (32-bit, non-prefetchable) [size=16M] Memory at d000 (64-bit, prefetchable) [size=256M] Memory at fa00 (64-bit, non-prefetchable) [size=32M] I/O ports at ec00 [size=128] Expansion ROM at feb8 [disabled] [size=512K] Capabilities: [60] Power Management version 3 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [78] Express Endpoint, MSI 00 Capabilities: [b4] Vendor Specific Information: Len=14 Capabilities: [100] Virtual Channel Capabilities: [128] Power Budgeting Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 Kernel driver in use: nouveau Kernel modules: nouveau Als Grafiktreiber versuche ich einen NOUVEAU zum Laufen zu bekommen. Die Xorg.0.Log gibt keinerlei Fehler aus / wollte die 31k nicht anhaengen. Ich habe gelesen, dass es am GLX liegen koennte, welches geladen wird. die frage waere, wie man es, wenn es dieses sein koennte, abschalten kann. MfG Robert ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Kein Bild bei X
Moin, kannst du bitte dmesg und die xorg.0.log in ein pastebin Service kopieren? Gruß Christopher Am Freitag, den 26.07.2013, 13:27 +0200 schrieb Robert Drechsel: > Hallo Leute, > > ich habe gerade das Problem bei einer Neuinstallation eines ArchLinux, > dass ich zwar in der Console Bild habe (auch in hoher Aufloesung) nur > sobald ich X starte ist der Bildschirm leer. > > Grafikkarte ist eine: > 04:00.0 VGA compatible controller: NVIDIA Corporation G96 [GeForce 9500 > GT] (rev a1) (prog-if 00 [VGA controller]) > Subsystem: Micro-Star International Co., Ltd. Device 1337 > Flags: bus master, fast devsel, latency 0, IRQ 17 > Memory at fd00 (32-bit, non-prefetchable) [size=16M] > Memory at d000 (64-bit, prefetchable) [size=256M] > Memory at fa00 (64-bit, non-prefetchable) [size=32M] > I/O ports at ec00 [size=128] > Expansion ROM at feb8 [disabled] [size=512K] > Capabilities: [60] Power Management version 3 > Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ > Capabilities: [78] Express Endpoint, MSI 00 > Capabilities: [b4] Vendor Specific Information: Len=14 > Capabilities: [100] Virtual Channel > Capabilities: [128] Power Budgeting > Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 > > Kernel driver in use: nouveau > Kernel modules: nouveau > > > > Als Grafiktreiber versuche ich einen NOUVEAU zum Laufen zu bekommen. > > Die Xorg.0.Log gibt keinerlei Fehler aus / wollte die 31k nicht anhaengen. > > Ich habe gelesen, dass es am GLX liegen koennte, welches geladen wird. > die frage waere, wie man es, wenn es dieses sein koennte, abschalten kann. > > > MfG > Robert > > ___ > Lug-dd maillist - Lug-dd@mailman.schlittermann.de > https://ssl.schlittermann.de/mailman/listinfo/lug-dd ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
AW: munin und Überschreiben von warn + crit (hier Plugin sensors)
Tippfehler : /etc/munin/plugin-conf.d/munin-node ist die Datei, in der ich die Überschreibungen ergänze (debian 7.1) Ergänzung : natürlich fergesse ich nicht den munin-node nach Änderung zum neuladen/-starten anzuweisen Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ro...@seffner.de | +49 35245 72950 ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
AW: munin und Überschreiben von warn + crit (hier Plugin sensors)
Mit der Manipulation von 'sensors' bin ich dank der Schalter -s und -u weiter. '-s' prüft die Config-Syntax und stellt fest Fehler in der Zeile, wo ich "temp4" erwähne. '-u' ist etwas ausführlicher bei der Sensordatenanzeige und sagt mir, dass SYSTIN nicht temp4 wie bei munin sondern temp1 ist Jetzt kann ich sensors konfigurieren, vielleicht auch die richtige Stelle, wer weiß wer zukünftig mal noch 'sensors' zu dieser Diode befragen könnte. Aber der Form halber will ich e noch wissen, wieso geht das Überschreiben im munin nicht? ps: ich finde wir kommen heute gut voran, 3 Anläufe diese Woche brachten mich nicht soweit ;-) Wenn sich noch einer erbarmt und mit das apt + upgradeable # *manually* Ding (Posts aus den gefühlt letzten 2 Wochen) erklärt ist mein Wochenende gerettet. Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ro...@seffner.de | +49 35245 72950 ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
munin und Überschreiben von warn + crit (hier Plugin sensors)
Weiter in dieser guten Gesellschaft mit meiner Liste "confusing things that costs already hours but were not worth a quarter" ;-) Gegeben sind je ein munin Client und Server. Vom Server zum Client liefern: fetch sensors_temp ... temp4.value 41.0 ... und config sensors_temp ... temp4.label SYSTIN temp4.warning 0.0 temp4.critical 0.0 ... Es wird also der Zustand CRITICAL ausgelöst, da eine Temperatur größer 0 geliefert wird. Das will ich ändern indem ich "warning" und "critical" ändere. Für viele Plugins mache ich das indem ich in der munin-node.conf auf dem Client etwas in der Art veranstalte [sensors*] env.temp4.warning 70 env.temp4.critical 85 (wahlweise kann ich Werte auch mit ".0" enden lassen, die Wirkung bleibt trotzdem aus) Schon hier verstehe ich nicht, warum sich die Variablen nicht wie bei anderen Plugins überschreiben lassen. Ok, wir könnten ja noch 'sensors' manipulieren: hp-gw-dd:~# sensors ... nct6775-isa-0290 ... SYSTIN: +41.0°C (high = +0.0°C, hyst = +0.0°C) ALARM sensor = CPU diode ... Hier nimmt munin bei config also die "0" her, den Chipsatz kennen wir jetzt auch, also ab nach sensors3.conf ... chip "w83627ehf-*" "w83627dhg-*" "w83667hg-*" "nct6775-*" "nct6776-*" set temp4_max 70 set temp4_crit 85 ... Juckt aber sensors weder in seiner Ausgabe noch munin (logisch). Was mache (oder erwarte) ich hier falsch? Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ro...@seffner.de | +49 35245 72950 ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
[solved] bind und forward einer zone geht nicht
Ist 'dnssec-validation' im bind an und betrachtet man die Validierung wie eine SSL-Zertifikatskette, so muss sich der Server zuerst den Key von der root Zone (TLD?) holen. In meinem Fall gibt es aber ".box" gar nicht. Die DNSSEC Implemetierung ist nun (vielleicht zu Recht) so empfindlich, dass sie nur "hier hast du den Key" (DS/DLV) oder "DNSSEC mache ich nicht" akzeptiert. Ein "die zone gibt es nicht" führt zu "Fehlvalidation". Ich habe also flink lokal die zone box angelegt, in der ich für die Subzone fritz den NS auf das remote Tunnelende setze. Nun gehts auch mit aktiviertem 'dnssec-validation'. Bestimmt hätte man für die Erklärung treffendere und korrekte Begriffe gefunden. Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ro...@seffner.de | +49 35245 72950 ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
AW: bind und forward einer zone geht nicht
Hallo Heiko, bei dem Wetter auch vor der "Klaviatur", gibt’s keine Aufwinde? >Wieso DS Abfrage? > Weil der lokale bind, wie in meinem 2. Post geschrieben 'dnssec-validation' auf 'on' hat. Eine gute Frage, die in die Richtige Richtung führt. >Geht das alles auch ohne DNSSec? > Nur ohne ging es. Erklärung(sversuch) in meinem "[solved]" Post. Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ro...@seffner.de | +49 35245 72950 ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
AW: bind und forward einer zone geht nicht
Ich hab mal 'rndc trace 9' angeworfen und bin über "validator" auf "dnssec-validation yes;" in meiner config gestoßen. Das ist offenbar der Schalter mit destruktiver Wirkung - nur leider gibts den ausschließlich global und warum eine geforwardete Zone mal nicht signiert sein darf ist mir auch noch ein Rätsel. Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ro...@seffner.de | +49 35245 72950 ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: bind und forward einer zone geht nicht
Ronny Seffner (Fr 26 Jul 2013 16:58:49 CEST):
> Hallo,
>
> es ist heiß, es ist Freitag und diese Woche ist die Liste der nicht gelösten
> Phänomene wieder gewachsen.
>
> In meiner named.conf.local auf IP 192.168.100.1 befindet sich folgender
> Abschnitt:
>
> zone "fritz.box" in {
> type forward;
> forward only;
> forwarders { 192.168.2.24; 192.168.99.2; };
> };
>
> Ich betreibe ein openvpn mit dem Tunnelende 192.168.2.24 in das Netz
> 192.168.99.0/24. Dort läuft auf der .2/32 (gleichzeitig das VPN-gateway
> [Fritz!Box] ein DNS-Server)
>
> Warum tritt nun Folgendes ein :
>
> its-gw:~dig nas.fritz.box @192.168.2.24
>
> ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> nas.fritz.box @192.168.2.24
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19911
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3
>
> ;; QUESTION SECTION:
> ;nas.fritz.box. IN A
>
> ;; ANSWER SECTION:
> nas.fritz.box. 9 IN A 192.168.99.3
>
> ;; AUTHORITY SECTION:
> nas.fritz.box. 9 IN NS fritz.box.
>
> ;; ADDITIONAL SECTION:
> fritz.box. 9 IN A 192.168.99.2
> fritz.box. 9 IN fd00::224:feff:feda:b39c
> fritz.box. 9 IN
>
> ;; Query time: 93 msec
> ;; SERVER: 192.168.2.24#53(192.168.2.24)
> ;; WHEN: Fri Jul 26 16:47:49 2013
> ;; MSG SIZE rcvd: 133
>
>
> its-gw:~# dig nas.fritz.box @127.0.0.1
>
> ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> nas.fritz.box @127.0.0.1
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51214
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;nas.fritz.box. IN A
>
> ;; Query time: 279 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Fri Jul 26 16:48:13 2013
> ;; MSG SIZE rcvd: 31
>
> Und dabei in der zweiten Sitzung (tcpdump am Tunnelinterface):
>
> 16:48:13.640380 IP 192.168.2.23.20457 > 192.168.2.24.53: 37460+% [1au] A?
> nas.fritz.box. (42)
> 16:48:13.732274 IP 192.168.2.24.53 > 192.168.2.23.20457: 37460* 1/1/3 A
> 192.168.99.3 (133)
> 16:48:13.732634 IP 192.168.2.23.54370 > 192.168.2.24.53: 34236+% [1au] DS?
> fritz.box. (38)
Wieso DS Abfrage?
> 16:48:13.824919 IP 192.168.2.24.53 > 192.168.2.23.54370: 34236* 0/1/0 (69)
Beantwortet wird die auch.
> 16:48:13.825243 IP 192.168.2.23.47124 > 192.168.2.24.53: 4250+% [1au] NS?
> box. (32)
> 16:48:13.918824 IP 192.168.2.24.53 > 192.168.2.23.47124: 4250 NXDomain 0/1/1
> (107)
Geht das alles auch ohne DNSSec?
> Das Phänomen in Worten:
> Eine DNS Anfrage zur remoten DNS-Zone an den remoten DNS-Server durch den
> Tunnel vom hießigen gateway funktioniert.
> Die selbe Anfrage an den lokalen DNS Server, der durch den Tunnel zum
> remoten DNS-Server forwarden sollte funktioniert _NICHT_.
> Beobachtet man dabei den Traffic im Tunnel sieht man allerdings die Anfrage
> sowie die _ANTWORT_.
"dig" macht kein DNSSec, wenn Du mit dem remoten Server direkt sprichst.
Wenn Du mit dem lokalen sprichst, scheint der der Meinung zu sein, DS
abfragen zu müssen?
--
Heiko
signature.asc
Description: Digital signature
___
Lug-dd maillist - Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: bind und forward einer zone geht nicht
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hallo,
ein Schuss ins blaue und ein bisschen ToFu: Was passiert, wenn du
statt zone fritz.box zone box einträgst?
Grüße!
morphium
Am 26.07.2013 16:58, schrieb Ronny Seffner:
> Hallo,
>
> es ist heiß, es ist Freitag und diese Woche ist die Liste der nicht
> gelösten Phänomene wieder gewachsen.
>
> In meiner named.conf.local auf IP 192.168.100.1 befindet sich
> folgender Abschnitt:
>
> zone "fritz.box" in { type forward; forward only; forwarders {
> 192.168.2.24; 192.168.99.2; }; };
>
> Ich betreibe ein openvpn mit dem Tunnelende 192.168.2.24 in das
> Netz 192.168.99.0/24. Dort läuft auf der .2/32 (gleichzeitig das
> VPN-gateway [Fritz!Box] ein DNS-Server)
>
> Warum tritt nun Folgendes ein :
>
> its-gw:~dig nas.fritz.box @192.168.2.24
>
> ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> nas.fritz.box @192.168.2.24
> ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode:
> QUERY, status: NOERROR, id: 19911 ;; flags: qr aa rd ra; QUERY: 1,
> ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3
>
> ;; QUESTION SECTION: ;nas.fritz.box. IN A
>
> ;; ANSWER SECTION: nas.fritz.box. 9 IN A
> 192.168.99.3
>
> ;; AUTHORITY SECTION: nas.fritz.box. 9 IN NS
> fritz.box.
>
> ;; ADDITIONAL SECTION: fritz.box. 9 IN A
> 192.168.99.2 fritz.box. 9 IN
> fd00::224:feff:feda:b39c fritz.box. 9 IN
>
>
> ;; Query time: 93 msec ;; SERVER: 192.168.2.24#53(192.168.2.24) ;;
> WHEN: Fri Jul 26 16:47:49 2013 ;; MSG SIZE rcvd: 133
>
>
> its-gw:~# dig nas.fritz.box @127.0.0.1
>
> ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> nas.fritz.box @127.0.0.1 ;;
> global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY,
> status: SERVFAIL, id: 51214 ;; flags: qr rd ra; QUERY: 1, ANSWER:
> 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION: ;nas.fritz.box. IN A
>
> ;; Query time: 279 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN:
> Fri Jul 26 16:48:13 2013 ;; MSG SIZE rcvd: 31
>
> Und dabei in der zweiten Sitzung (tcpdump am Tunnelinterface):
>
> 16:48:13.640380 IP 192.168.2.23.20457 > 192.168.2.24.53: 37460+%
> [1au] A? nas.fritz.box. (42) 16:48:13.732274 IP 192.168.2.24.53 >
> 192.168.2.23.20457: 37460* 1/1/3 A 192.168.99.3 (133)
> 16:48:13.732634 IP 192.168.2.23.54370 > 192.168.2.24.53: 34236+%
> [1au] DS? fritz.box. (38) 16:48:13.824919 IP 192.168.2.24.53 >
> 192.168.2.23.54370: 34236* 0/1/0 (69) 16:48:13.825243 IP
> 192.168.2.23.47124 > 192.168.2.24.53: 4250+% [1au] NS? box. (32)
> 16:48:13.918824 IP 192.168.2.24.53 > 192.168.2.23.47124: 4250
> NXDomain 0/1/1 (107)
>
> Das Phänomen in Worten: Eine DNS Anfrage zur remoten DNS-Zone an
> den remoten DNS-Server durch den Tunnel vom hießigen gateway
> funktioniert. Die selbe Anfrage an den lokalen DNS Server, der
> durch den Tunnel zum remoten DNS-Server forwarden sollte
> funktioniert _NICHT_. Beobachtet man dabei den Traffic im Tunnel
> sieht man allerdings die Anfrage sowie die _ANTWORT_.
>
> Wo liegt hier das Problem?
>
>
> Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny
> Seffner | Alter Viehweg 1 | 01665 Klipphausen
>
> www.seffner.de | ro...@seffner.de | +49 35245 72950
>
>
>
> ___ Lug-dd maillist -
> Lug-dd@mailman.schlittermann.de
> https://ssl.schlittermann.de/mailman/listinfo/lug-dd
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17
iEYEARECAAYFAlHymG0ACgkQTYqYQhcm1/fLNQCgxC2DvSdkYlBboV7hzLgYiY0H
W+8AoNh0PfpU+bLwb1ldzjI8g90KtZrG
=ZeKh
-END PGP SIGNATURE-
___
Lug-dd maillist - Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd
bind und forward einer zone geht nicht
Hallo,
es ist heiß, es ist Freitag und diese Woche ist die Liste der nicht gelösten
Phänomene wieder gewachsen.
In meiner named.conf.local auf IP 192.168.100.1 befindet sich folgender
Abschnitt:
zone "fritz.box" in {
type forward;
forward only;
forwarders { 192.168.2.24; 192.168.99.2; };
};
Ich betreibe ein openvpn mit dem Tunnelende 192.168.2.24 in das Netz
192.168.99.0/24. Dort läuft auf der .2/32 (gleichzeitig das VPN-gateway
[Fritz!Box] ein DNS-Server)
Warum tritt nun Folgendes ein :
its-gw:~dig nas.fritz.box @192.168.2.24
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> nas.fritz.box @192.168.2.24
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19911
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3
;; QUESTION SECTION:
;nas.fritz.box. IN A
;; ANSWER SECTION:
nas.fritz.box. 9 IN A 192.168.99.3
;; AUTHORITY SECTION:
nas.fritz.box. 9 IN NS fritz.box.
;; ADDITIONAL SECTION:
fritz.box. 9 IN A 192.168.99.2
fritz.box. 9 IN fd00::224:feff:feda:b39c
fritz.box. 9 IN
;; Query time: 93 msec
;; SERVER: 192.168.2.24#53(192.168.2.24)
;; WHEN: Fri Jul 26 16:47:49 2013
;; MSG SIZE rcvd: 133
its-gw:~# dig nas.fritz.box @127.0.0.1
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> nas.fritz.box @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51214
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;nas.fritz.box. IN A
;; Query time: 279 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jul 26 16:48:13 2013
;; MSG SIZE rcvd: 31
Und dabei in der zweiten Sitzung (tcpdump am Tunnelinterface):
16:48:13.640380 IP 192.168.2.23.20457 > 192.168.2.24.53: 37460+% [1au] A?
nas.fritz.box. (42)
16:48:13.732274 IP 192.168.2.24.53 > 192.168.2.23.20457: 37460* 1/1/3 A
192.168.99.3 (133)
16:48:13.732634 IP 192.168.2.23.54370 > 192.168.2.24.53: 34236+% [1au] DS?
fritz.box. (38)
16:48:13.824919 IP 192.168.2.24.53 > 192.168.2.23.54370: 34236* 0/1/0 (69)
16:48:13.825243 IP 192.168.2.23.47124 > 192.168.2.24.53: 4250+% [1au] NS?
box. (32)
16:48:13.918824 IP 192.168.2.24.53 > 192.168.2.23.47124: 4250 NXDomain 0/1/1
(107)
Das Phänomen in Worten:
Eine DNS Anfrage zur remoten DNS-Zone an den remoten DNS-Server durch den
Tunnel vom hießigen gateway funktioniert.
Die selbe Anfrage an den lokalen DNS Server, der durch den Tunnel zum
remoten DNS-Server forwarden sollte funktioniert _NICHT_.
Beobachtet man dabei den Traffic im Tunnel sieht man allerdings die Anfrage
sowie die _ANTWORT_.
Wo liegt hier das Problem?
Mit freundlichen Grüßen / Kind regards
Ronny Seffner
--
Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen
www.seffner.de | ro...@seffner.de | +49 35245 72950
___
Lug-dd maillist - Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Kein Bild bei X
Hallo Leute, ich habe gerade das Problem bei einer Neuinstallation eines ArchLinux, dass ich zwar in der Console Bild habe (auch in hoher Aufloesung) nur sobald ich X starte ist der Bildschirm leer. Grafikkarte ist eine: 04:00.0 VGA compatible controller: NVIDIA Corporation G96 [GeForce 9500 GT] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. Device 1337 Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at fd00 (32-bit, non-prefetchable) [size=16M] Memory at d000 (64-bit, prefetchable) [size=256M] Memory at fa00 (64-bit, non-prefetchable) [size=32M] I/O ports at ec00 [size=128] Expansion ROM at feb8 [disabled] [size=512K] Capabilities: [60] Power Management version 3 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [78] Express Endpoint, MSI 00 Capabilities: [b4] Vendor Specific Information: Len=14 Capabilities: [100] Virtual Channel Capabilities: [128] Power Budgeting Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 Kernel driver in use: nouveau Kernel modules: nouveau Als Grafiktreiber versuche ich einen NOUVEAU zum Laufen zu bekommen. Die Xorg.0.Log gibt keinerlei Fehler aus / wollte die 31k nicht anhaengen. Ich habe gelesen, dass es am GLX liegen koennte, welches geladen wird. die frage waere, wie man es, wenn es dieses sein koennte, abschalten kann. MfG Robert ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
ressourcen einschränken
Hi eigentlich will ich die RAM-Nutzung bestimmter programme einschränken. Da die produktive System mit einen Enteprise Linux ausgestatte sind wo es noch keine cgroups gibt bleibt mir nur der weg über limits.conf (Unsere Erfahrungen sind nutzt das Programm, Grafikmanipulation, mehr als 2GB Ram dann wird es in 95% der Fälle wenn es dann irgendwann keinen RAM mehr gibt abstürzen. Bis zum Absturz dauert es und in der Zeit passiert nichts also wollen wir den "Absturz" ehr erzwingen, da wird das File "händig" bearbeitet. Also will ich den User der das Programm startet einschränken --- limits.conf: ... twist hard memlock 2097152 twist soft memlock 1048576 ## ##memlock - max locked-in-memory address space (KB) --- Leider finde ich keine weiteresn Angabe dazu, Die RAM nutzung ist nicht gleich der "memlock" kennt jemand eine Berechnungsformel? Kennt jemand eine andere Lösung wie man die RAM-Nutzung von Programmen einschränkt Danke Andreas ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Paging & Swapping
On 25.07.13 Peter Hochgemuth (210567...@web.de) wrote: Moin, > Schau mal im top - die Zahl bei "Swap: xxx used", zeigt wieviel > ausgelagert ist und bei deinen 106 pages müssten das dann 424k sein. > Die Zahlen die man in /proc/vmstat sieht sind ja nur die Counter, also hier werden die Pages In/Out hochgezählt. Im top hingegen sieht man die aktuellen/absoluten Werte. Die Zahlen sollten also nicht vergleichbar sein. > Wie gesagt, swap geht erst los, wenn der Haupspeicher voll (Daten) > ist. > Laut A. Lingnau (und dem glaube ich das mal) gibt es sowieso kein Swapping (komplettes Auslagern von Programmen) mehr, sondern nur noch Paging (seitenweises Auslagern von Programmen). Das nur am Rande. Was mich leider nicht weiterbringt bei der Frage was die beiden Werte in /proc/vmstat wirklich bedeuten. Ich halte mich vorläufig an den Kommentar im Quellcode, wenn der auch in einer arch-spezifischen Datei war, trifft er hoffentlich auch für die andere Arches zu. H. -- I need to discuss BUY-BACK PROVISIONS with at least six studio SLEAZEBALLS!! http://www.hilmar-preusse.de.vu/ signature.asc Description: Digital signature ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
