- <title>How to use the Signal app if you only have a land line (ie no mobile phone)</title>
- <link>http://people.skolelinux.org/pere/blog/How_to_use_the_Signal_app_if_you_only_have_a_land_line__ie_no_mobile_phone_.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/How_to_use_the_Signal_app_if_you_only_have_a_land_line__ie_no_mobile_phone_.html</guid>
- <pubDate>Sun, 3 Jul 2016 14:20:00 +0200</pubDate>
- <description><p>For a while now, I have wanted to test
-<a href="https://whispersystems.org/">the Signal app</a>, as it is
-said to provide end to end encrypted communication and several of my
-friends and family are already using it. As I by choice do not own a
-mobile phone, this proved to be harder than expected. And I wanted to
-have the source of the client and know that it was the code used on my
-machine. But yesterday I managed to get it working. I used the
-Github source, compared it to the source in
-<a href="https://chrome.google.com/webstore/detail/signal-private-messenger/bikioccmkafdpakkkcpdbppfkghcmihk?hl=en-US">the
-Signal Chrome app</a> available from the Chrome web store, applied
-patches to use the production Signal servers, started the app and
-asked for the hidden "register without a smart phone" form. Here is
-the recipe how I did it.</p>
-
-<p>First, I fetched the Signal desktop source from Github, using
-
-<pre>
-git clone https://github.com/WhisperSystems/Signal-Desktop.git
-</pre>
-
-<p>Next, I patched the source to use the production servers, to be
-able to talk to other Signal users:</p>
-
-<pre>
-cat &lt;&lt;EOF | patch -p0
-diff -ur ./js/background.js userdata/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.15.0_0/js/background.js
---- ./js/background.js 2016-06-29 13:43:15.630344628 +0200
-+++ userdata/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.15.0_0/js/background.js 2016-06-29 14:06:29.530300934 +0200
-@@ -47,8 +47,8 @@
- });
- });
-
-- var SERVER_URL = 'https://textsecure-service-staging.whispersystems.org';
-- var ATTACHMENT_SERVER_URL = 'https://whispersystems-textsecure-attachments-staging.s3.amazonaws.com';
-+ var SERVER_URL = 'https://textsecure-service-ca.whispersystems.org:4433';
-+ var ATTACHMENT_SERVER_URL = 'https://whispersystems-textsecure-attachments.s3.amazonaws.com';
- var messageReceiver;
- window.getSocketStatus = function() {
- if (messageReceiver) {
-diff -ur ./js/expire.js userdata/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.15.0_0/js/expire.js
---- ./js/expire.js 2016-06-29 13:43:15.630344628 +0200
-+++ userdata/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.15.0_0/js/expire.js2016-06-29 14:06:29.530300934 +0200
-@@ -1,6 +1,6 @@
- ;(function() {
- 'use strict';
-- var BUILD_EXPIRATION = 0;
-+ var BUILD_EXPIRATION = 1474492690000;
-
- window.extension = window.extension || {};
-
-EOF
-</pre>
-
-<p>The first part is changing the servers, and the second is updating
-an expiration timestamp. This timestamp need to be updated regularly.
-It is set 90 days in the future by the build process (Gruntfile.js).
-The value is seconds since 1970 times 1000, as far as I can tell.</p>
-
-<p>Based on a tip and good help from the #nuug IRC channel, I wrote a
-script to launch Signal in Chromium.</p>
-
-<pre>
-#!/bin/sh
-cd $(dirname $0)
-mkdir -p userdata
-exec chromium \
- --proxy-server="socks://localhost:9050" \
- --user-data-dir=`pwd`/userdata --load-and-launch-app=`pwd`
-</pre>
-
-<p> The script start the app and configure Chromium to use the Tor
-SOCKS5 proxy to make sure those controlling the Signal servers (today
-Amazon and Whisper Systems) as well as those listening on the lines
-will have a harder time location my laptop based on the Signal
-connections if they use source IP address.</p>
-
-<p>When the script starts, one need to follow the instructions under
-"Standalone Registration" in the CONTRIBUTING.md file in the git
-repository. I right clicked on the Signal window to get up the
-Chromium debugging tool, visited the 'Console' tab and wrote
-'extension.install("standalone")' on the console prompt to get the
-registration form. Then I entered by land line phone number and
-pressed 'Call'. 5 seconds later the phone rang and a robot voice
-repeated the verification code three times. After entering the number
-into the verification code field in the form, I could start using
-Signal from my laptop.
-
-<p>As far as I can tell, The Signal app will leak who is talking to
-whom and thus who know who to those controlling the central server,
-but such leakage is hard to avoid with a centrally controlled server
-setup. It is something to keep in mind when using Signal - the
-content of your chats are harder to intercept, but the meta data
-exposing your contact network is available to people you do not know.
-So better than many options, but not great. And sadly the usage is
-connected to my land line, thus allowing those controlling the server
-to associate it to my home and person. I would prefer it if only
-those I knew could tell who I was on Signal. There are options
-avoiding such information leakage, but most of my friends are not
-using them, so I am stuck with Signal for now.</p>
+ <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>
projects / homepage.git / blobdiff