- <title>E-tjenesten ber om innsyn i eposten til partiene på Stortinget</title>
- <link>http://people.skolelinux.org/pere/blog/E_tjenesten_ber_om_innsyn_i_eposten_til_partiene_p__Stortinget.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/E_tjenesten_ber_om_innsyn_i_eposten_til_partiene_p__Stortinget.html</guid>
- <pubDate>Tue, 6 Sep 2016 23:00:00 +0200</pubDate>
- <description><p>I helga kom det et hårreisende forslag fra Lysne II-utvalget satt
-ned av Forsvarsdepartementet. Lysne II-utvalget var bedt om å vurdere
-ønskelista til Forsvarets etterretningstjeneste (e-tjenesten), og har
-kommet med
-<a href="http://www.aftenposten.no/norge/Utvalg-sier-ja-til-at-E-tjenesten-far-overvake-innholdet-i-all-internett--og-telefontrafikk-som-krysser-riksgrensen-603232b.html">forslag
-om at e-tjenesten skal få lov til a avlytte all Internett-trafikk</a>
-som passerer Norges grenser. Få er klar over at dette innebærer at
-e-tjenesten får tilgang til epost sendt til de fleste politiske
-partiene på Stortinget. Regjeringspartiet Høyre (@hoyre.no),
-støttepartiene Venstre (@venstre.no) og Kristelig Folkeparti (@krf.no)
-samt Sosialistisk Ventreparti (@sv.no) og Miljøpartiet de grønne
-(@mdg.no) har nemlig alle valgt å ta imot eposten sin via utenlandske
-tjenester. Det betyr at hvis noen sender epost til noen med en slik
-adresse vil innholdet i eposten, om dette forslaget blir vedtatt, gjøres
-tilgjengelig for e-tjenesten. Venstre, Sosialistisk Ventreparti og
-Miljøpartiet De Grønne har valgt å motta sin epost hos Google,
-Kristelig Folkeparti har valgt å motta sin epost hos Microsoft, og
-Høyre har valgt å motta sin epost hos Comendo med mottak i Danmark og
-Irland. Kun Arbeiderpartiet og Fremskrittspartiet har valgt å motta
-eposten sin i Norge, hos henholdsvis Intility AS og Telecomputing
-AS.</p>
-
-<p>Konsekvensen er at epost inn og ut av de politiske organisasjonene,
-til og fra partimedlemmer og partiets tillitsvalgte vil gjøres
-tilgjengelig for e-tjenesten for analyse og sortering. Jeg mistenker
-at kunnskapen som slik blir tilgjengelig vil være nyttig hvis en
-ønsker å vite hvilke argumenter som treffer publikum når en ønsker å
-påvirke Stortingets representanter.</p
-
-<p>Ved hjelp av MX-oppslag i DNS for epost-domene, tilhørende
-whois-oppslag av IP-adressene og traceroute for å se hvorvidt
-trafikken går via utlandet kan enhver få bekreftet at epost sendt til
-de omtalte partiene vil gjøres tilgjengelig for forsvarets
-etterretningstjeneste hvis forslaget blir vedtatt. En kan også bruke
-den kjekke nett-tjenesten <a href="http://ipinfo.io/">ipinfo.io</a>
-for å få en ide om hvor i verden en IP-adresse hører til.</p>
-
-<p>På den positive siden vil forslaget gjøre at enda flere blir
-motivert til å ta grep for å bruke
-<a href="https://www.torproject.org/">Tor</a> og krypterte
-kommunikasjonsløsninger for å kommunisere med sine kjære, for å sikre
-at privatsfæren vernes. Selv bruker jeg blant annet
-<a href="https://www.freedomboxfoundation.org/">FreedomBox</a> og
-<a href="https://whispersystems.org/">Signal</a> til slikt. Ingen av
-dem er optimale, men de fungerer ganske bra allerede og øker kostnaden
-for dem som ønsker å invadere mitt privatliv.</p>
-
-<p>For øvrig burde varsleren Edward Snowden få politisk asyl i
-Norge.</p>
-
-<!--
-
-venstre.no
- venstre.no mail is handled by 10 aspmx.l.google.com.
- venstre.no mail is handled by 20 alt1.aspmx.l.google.com.
- venstre.no mail is handled by 20 alt2.aspmx.l.google.com.
- venstre.no mail is handled by 30 aspmx2.googlemail.com.
- venstre.no mail is handled by 30 aspmx3.googlemail.com.
-
-traceroute to aspmx.l.google.com (173.194.222.27), 30 hops max, 60 byte packets
- 1 uio-gw10.uio.no (129.240.6.1) 0.411 ms 0.438 ms 0.536 ms
- 2 uio-gw8.uio.no (129.240.24.229) 0.375 ms 0.452 ms 0.548 ms
- 3 oslo-gw1.uninett.no (128.39.65.17) 1.940 ms 1.950 ms 1.942 ms
- 4 se-tug.nordu.net (109.105.102.108) 6.910 ms 6.949 ms 7.283 ms
- 5 google-gw.nordu.net (109.105.98.6) 6.975 ms 6.967 ms 6.958 ms
- 6 209.85.250.192 (209.85.250.192) 7.337 ms 7.286 ms 10.890 ms
- 7 209.85.254.13 (209.85.254.13) 7.394 ms 209.85.254.31 (209.85.254.31) 7.586 ms 209.85.254.33 (209.85.254.33) 7.570 ms
- 8 209.85.251.255 (209.85.251.255) 15.686 ms 209.85.249.229 (209.85.249.229) 16.118 ms 209.85.251.255 (209.85.251.255) 16.073 ms
- 9 74.125.37.255 (74.125.37.255) 16.794 ms 216.239.40.248 (216.239.40.248) 16.113 ms 74.125.37.44 (74.125.37.44) 16.764 ms
-10 * * *
-
-mdg.no
- mdg.no mail is handled by 1 aspmx.l.google.com.
- mdg.no mail is handled by 5 alt2.aspmx.l.google.com.
- mdg.no mail is handled by 5 alt1.aspmx.l.google.com.
- mdg.no mail is handled by 10 aspmx2.googlemail.com.
- mdg.no mail is handled by 10 aspmx3.googlemail.com.
-sv.no
- sv.no mail is handled by 1 aspmx.l.google.com.
- sv.no mail is handled by 5 alt1.aspmx.l.google.com.
- sv.no mail is handled by 5 alt2.aspmx.l.google.com.
- sv.no mail is handled by 10 aspmx3.googlemail.com.
- sv.no mail is handled by 10 aspmx2.googlemail.com.
-hoyre.no
- hoyre.no mail is handled by 10 hoyre-no.mx1.comendosystems.com.
- hoyre.no mail is handled by 20 hoyre-no.mx2.comendosystems.net.
-
-traceroute to hoyre-no.mx1.comendosystems.com (89.104.206.4), 30 hops max, 60 byte packets
- 1 uio-gw10.uio.no (129.240.6.1) 0.450 ms 0.510 ms 0.591 ms
- 2 uio-gw8.uio.no (129.240.24.229) 0.383 ms 0.508 ms 0.596 ms
- 3 oslo-gw1.uninett.no (128.39.65.17) 0.311 ms 0.315 ms 0.300 ms
- 4 se-tug.nordu.net (109.105.102.108) 6.837 ms 6.842 ms 6.834 ms
- 5 dk-uni.nordu.net (109.105.97.10) 26.073 ms 26.085 ms 26.076 ms
- 6 dix.1000m.soeborg.ip.comendo.dk (192.38.7.22) 15.372 ms 15.046 ms 15.123 ms
- 7 89.104.192.65 (89.104.192.65) 15.875 ms 15.990 ms 16.239 ms
- 8 89.104.192.179 (89.104.192.179) 15.676 ms 15.674 ms 15.664 ms
- 9 03dm-com.mx1.staysecuregroup.com (89.104.206.4) 15.637 ms * *
-
-krf.no
- krf.no mail is handled by 10 krf-no.mail.protection.outlook.com.
-
-traceroute to krf-no.mail.protection.outlook.com (213.199.154.42), 30 hops max, 60 byte packets
- 1 uio-gw10.uio.no (129.240.6.1) 0.401 ms 0.438 ms 0.536 ms
- 2 uio-gw8.uio.no (129.240.24.229) 11.076 ms 11.120 ms 11.204 ms
- 3 oslo-gw1.uninett.no (128.39.65.17) 0.232 ms 0.234 ms 0.271 ms
- 4 se-tug.nordu.net (109.105.102.108) 6.811 ms 6.820 ms 6.815 ms
- 5 netnod-ix-ge-a-sth-4470.microsoft.com (195.245.240.181) 7.074 ms 7.013 ms 7.061 ms
- 6 ae1-0.sto-96cbe-1b.ntwk.msn.net (104.44.225.161) 7.227 ms 7.362 ms 7.293 ms
- 7 be-8-0.ibr01.ams.ntwk.msn.net (104.44.5.7) 41.993 ms 43.334 ms 41.939 ms
- 8 be-1-0.ibr02.ams.ntwk.msn.net (104.44.4.214) 43.153 ms 43.507 ms 43.404 ms
- 9 ae3-0.fra-96cbe-1b.ntwk.msn.net (104.44.5.17) 29.897 ms 29.831 ms 29.794 ms
-10 ae10-0.vie-96cbe-1a.ntwk.msn.net (198.206.164.1) 42.309 ms 42.130 ms 41.808 ms
-11 * ae8-0.vie-96cbe-1b.ntwk.msn.net (104.44.227.29) 41.425 ms *
-12 * * *
-
-arbeiderpartiet.no
- arbeiderpartiet.no mail is handled by 10 mail.intility.com.
- arbeiderpartiet.no mail is handled by 20 mail2.intility.com.
-
-traceroute to mail.intility.com (188.95.245.87), 30 hops max, 60 byte packets
- 1 uio-gw10.uio.no (129.240.6.1) 0.486 ms 0.508 ms 0.649 ms
- 2 uio-gw8.uio.no (129.240.24.229) 0.416 ms 0.508 ms 0.620 ms
- 3 oslo-gw1.uninett.no (128.39.65.17) 0.276 ms 0.278 ms 0.275 ms
- 4 te3-1-2.br1.fn3.as2116.net (193.156.90.3) 0.374 ms 0.371 ms 0.416 ms
- 5 he16-1-1.cr1.san110.as2116.net (195.0.244.234) 3.132 ms he16-1-1.cr2.oslosda310.as2116.net (195.0.244.48) 10.079 ms he16-1-1.cr1.san110.as2116.net (195.0.244.234) 3.353 ms
- 6 te1-2-0.ar2.ulv89.as2116.net (195.0.243.194) 0.569 ms te5-0-0.ar2.ulv89.as2116.net (195.0.243.192) 0.661 ms 0.653 ms
- 7 cD2EC45C1.static.as2116.net (193.69.236.210) 0.654 ms 0.615 ms 0.590 ms
- 8 185.7.132.38 (185.7.132.38) 1.661 ms 1.808 ms 1.695 ms
- 9 185.7.132.100 (185.7.132.100) 1.793 ms 1.943 ms 1.546 ms
-10 * * *
-
-frp.no
- frp.no mail is handled by 10 mx03.telecomputing.no.
- frp.no mail is handled by 20 mx01.telecomputing.no.
-
-traceroute to mx03.telecomputing.no (95.128.105.102), 30 hops max, 60 byte packets
- 1 uio-gw10.uio.no (129.240.6.1) 0.378 ms 0.402 ms 0.479 ms
- 2 uio-gw8.uio.no (129.240.24.229) 0.361 ms 0.458 ms 0.548 ms
- 3 oslo-gw1.uninett.no (128.39.65.17) 0.361 ms 0.352 ms 0.336 ms
- 4 xe-2-2-0-0.san-peer2.osl.no.ip.tdc.net (193.156.90.16) 0.375 ms 0.366 ms 0.346 ms
- 5 xe-2-0-2-0.ost-pe1.osl.no.ip.tdc.net (85.19.121.97) 0.780 ms xe-2-0-0-0.ost-pe1.osl.no.ip.tdc.net (85.19.121.101) 0.713 ms xe-2-0-2-0.ost-pe1.osl.no.ip.tdc.net (85.19.121.97) 0.759 ms
- 6 cpe.xe-0-2-0-100.ost-pe1.osl.no.customer.tdc.net (85.19.26.46) 0.837 ms 0.755 ms 0.759 ms
- 7 95.128.105.3 (95.128.105.3) 1.050 ms 1.288 ms 1.182 ms
- 8 mx03.telecomputing.no (95.128.105.102) 0.717 ms 0.703 ms 0.692 ms
-
--->
+ <title>Detecting NFS hangs on Linux without hanging yourself...</title>
+ <link>http://people.skolelinux.org/pere/blog/Detecting_NFS_hangs_on_Linux_without_hanging_yourself___.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Detecting_NFS_hangs_on_Linux_without_hanging_yourself___.html</guid>
+ <pubDate>Thu, 9 Mar 2017 15:20:00 +0100</pubDate>
+ <description><p>Over the years, administrating thousand of NFS mounting linux
+computers at the time, I often needed a way to detect if the machine
+was experiencing NFS hang. If you try to use <tt>df</tt> or look at a
+file or directory affected by the hang, the process (and possibly the
+shell) will hang too. So you want to be able to detect this without
+risking the detection process getting stuck too. It has not been
+obvious how to do this. When the hang has lasted a while, it is
+possible to find messages like these in dmesg:</p>
+
+<p><blockquote>
+nfs: server nfsserver not responding, still trying
+<br>nfs: server nfsserver OK
+</blockquote></p>
+
+<p>It is hard to know if the hang is still going on, and it is hard to
+be sure looking in dmesg is going to work. If there are lots of other
+messages in dmesg the lines might have rotated out of site before they
+are noticed.</p>
+
+<p>While reading through the nfs client implementation in linux kernel
+code, I came across some statistics that seem to give a way to detect
+it. The om_timeouts sunrpc value in the kernel will increase every
+time the above log entry is inserted into dmesg. And after digging a
+bit further, I discovered that this value show up in
+/proc/self/mountstats on Linux.</p>
+
+<p>The mountstats content seem to be shared between files using the
+same file system context, so it is enough to check one of the
+mountstats files to get the state of the mount point for the machine.
+I assume this will not show lazy umounted NFS points, nor NFS mount
+points in a different process context (ie with a different filesystem
+view), but that does not worry me.</p>
+
+<p>The content for a NFS mount point look similar to this:</p>
+
+<p><blockquote><pre>
+[...]
+device /dev/mapper/Debian-var mounted on /var with fstype ext3
+device nfsserver:/mnt/nfsserver/home0 mounted on /mnt/nfsserver/home0 with fstype nfs statvers=1.1
+ opts: rw,vers=3,rsize=65536,wsize=65536,namlen=255,acregmin=3,acregmax=60,acdirmin=30,acdirmax=60,soft,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=129.240.3.145,mountvers=3,mountport=4048,mountproto=udp,local_lock=all
+ age: 7863311
+ caps: caps=0x3fe7,wtmult=4096,dtsize=8192,bsize=0,namlen=255
+ sec: flavor=1,pseudoflavor=1
+ events: 61063112 732346265 1028140 35486205 16220064 8162542 761447191 71714012 37189 3891185 45561809 110486139 4850138 420353 15449177 296502 52736725 13523379 0 52182 9016896 1231 0 0 0 0 0
+ bytes: 166253035039 219519120027 0 0 40783504807 185466229638 11677877 45561809
+ RPC iostats version: 1.0 p/v: 100003/3 (nfs)
+ xprt: tcp 925 1 6810 0 0 111505412 111480497 109 2672418560317 0 248 53869103 22481820
+ per-op statistics
+ NULL: 0 0 0 0 0 0 0 0
+ GETATTR: 61063106 61063108 0 9621383060 6839064400 453650 77291321 78926132
+ SETATTR: 463469 463470 0 92005440 66739536 63787 603235 687943
+ LOOKUP: 17021657 17021657 0 3354097764 4013442928 57216 35125459 35566511
+ ACCESS: 14281703 14290009 5 2318400592 1713803640 1709282 4865144 7130140
+ READLINK: 125 125 0 20472 18620 0 1112 1118
+ READ: 4214236 4214237 0 715608524 41328653212 89884 22622768 22806693
+ WRITE: 8479010 8494376 22 187695798568 1356087148 178264904 51506907 231671771
+ CREATE: 171708 171708 0 38084748 46702272 873 1041833 1050398
+ MKDIR: 3680 3680 0 773980 993920 26 23990 24245
+ SYMLINK: 903 903 0 233428 245488 6 5865 5917
+ MKNOD: 80 80 0 20148 21760 0 299 304
+ REMOVE: 429921 429921 0 79796004 61908192 3313 2710416 2741636
+ RMDIR: 3367 3367 0 645112 484848 22 5782 6002
+ RENAME: 466201 466201 0 130026184 121212260 7075 5935207 5961288
+ LINK: 289155 289155 0 72775556 67083960 2199 2565060 2585579
+ READDIR: 2933237 2933237 0 516506204 13973833412 10385 3190199 3297917
+ READDIRPLUS: 1652839 1652839 0 298640972 6895997744 84735 14307895 14448937
+ FSSTAT: 6144 6144 0 1010516 1032192 51 9654 10022
+ FSINFO: 2 2 0 232 328 0 1 1
+ PATHCONF: 1 1 0 116 140 0 0 0
+ COMMIT: 0 0 0 0 0 0 0 0
+
+device binfmt_misc mounted on /proc/sys/fs/binfmt_misc with fstype binfmt_misc
+[...]
+</pre></blockquote></p>
+
+<p>The key number to look at is the third number in the per-op list.
+It is the number of NFS timeouts experiences per file system
+operation. Here 22 write timeouts and 5 access timeouts. If these
+numbers are increasing, I believe the machine is experiencing NFS
+hang. Unfortunately the timeout value do not start to increase right
+away. The NFS operations need to time out first, and this can take a
+while. The exact timeout value depend on the setup. For example the
+defaults for TCP and UDP mount points are quite different, and the
+timeout value is affected by the soft, hard, timeo and retrans NFS
+mount options.</p>
+
+<p>The only way I have been able to get working on Debian and RedHat
+Enterprise Linux for getting the timeout count is to peek in /proc/.
+But according to
+<ahref="http://docs.oracle.com/cd/E19253-01/816-4555/netmonitor-12/index.html">Solaris
+10 System Administration Guide: Network Services</a>, the 'nfsstat -c'
+command can be used to get these timeout values. But this do not work
+on Linux, as far as I can tell. I
+<ahref="http://bugs.debian.org/857043">asked Debian about this</a>,
+but have not seen any replies yet.</p>
+
+<p>Is there a better way to figure out if a Linux NFS client is
+experiencing NFS hangs? Is there a way to detect which processes are
+affected? Is there a way to get the NFS mount going quickly once the
+network problem causing the NFS hang has been cleared? I would very
+much welcome some clues, as we regularly run into NFS hangs.</p>