From MAILER-DAEMON Wed Feb 05 10:25:05 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1izMY4-0005Mr-W7 for mharc-lmi@gnu.org; Wed, 05 Feb 2020 10:25:05 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45625) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izMY2-0005Iz-Ap for lmi@nongnu.org; Wed, 05 Feb 2020 10:25:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1izMY1-0001IB-2O for lmi@nongnu.org; Wed, 05 Feb 2020 10:25:01 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:36334 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1izMY0-0000wc-Py for lmi@nongnu.org; Wed, 05 Feb 2020 10:25:01 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1izMXw-0001ec-D4; Wed, 05 Feb 2020 16:24:56 +0100 Date: Wed, 5 Feb 2020 16:24:56 +0100 From: Vadim Zeitlin To: lmi@nongnu.org, Greg Chicares MIME-Version: 1.0 Content-Type: MULTIPART/SIGNED; protocol="application/pgp-signature"; micalg=pgp-sha1; BOUNDARY="4294967295-41-1580916296=:29216" References: <20200205151607.18069.39206@vcs0.savannah.gnu.org> <20200205151608.5098B21049@vcs0.savannah.gnu.org> In-Reply-To: <20200205151608.5098B21049@vcs0.savannah.gnu.org> X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.240.17.225 Subject: Re: [lmi] [lmi-commits] master 4eca5fa 1/3: Suppress a redhat nuisance X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 15:25:03 -0000 --4294967295-41-1580916296=:29216 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE On Wed, 5 Feb 2020 10:16:08 -0500 (EST) Greg Chicares wrote: GC> branch: master GC> commit 4eca5fa1336e12ae26245abd0aee50231bff5e35 GC> Author: Gregory W. Chicares GC> Commit: Gregory W. Chicares GC> GC> Suppress a redhat nuisance GC> --- GC> install_centos.sh | 4 ++++ GC> install_redhat.sh | 4 ++++ GC> 2 files changed, 8 insertions(+) GC> GC> diff --git a/install_centos.sh b/install_centos.sh GC> index f5e35b4..ab74f32 100755 GC> --- a/install_centos.sh GC> +++ b/install_centos.sh GC> @@ -89,6 +89,10 @@ yum --assumeyes install ncurses-term zsh GC> chsh -s /bin/zsh root GC> chsh -s /bin/zsh "${NORMAL_USER}" GC> GC> +# Suppress a nuisance: rh-based distributions provide a default GC> +# zsh logout file that clears the screen. GC> +sed -e'/^[^#]/s/^/# SUPPRESSED # /' -i /srv/chroot/centos7lmi/etc/zlogout Just in case it can be useful: you could also add the following line to your ~/.zlogout file (creating it if necessary): unsetopt GLOBAL_RCS This would inhibit /etc/zlogout (or /etc/zsh/zlogout or whatever) from being read. Of course, you could also unset GLOBAL_RCS earlier if you don't want to use /etc/z{profile,shrc,login} neither, but doing it in ~/.zlogout is the least disruptive way to skip /etc/zlogout. Regards, VZ --4294967295-41-1580916296=:29216 Content-Type: APPLICATION/PGP-SIGNATURE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iEYEABECAAYFAl463kgACgkQBupB3k9sHob40ACePDNkPVVbDxiOPP2UkTIVzjEY Fl4AnAmXwJq/zE6gs7mT/wOD5r+XLQCu =jSbu -----END PGP SIGNATURE----- --4294967295-41-1580916296=:29216-- From MAILER-DAEMON Wed Feb 05 12:30:50 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1izOVl-0003Fs-Dy for mharc-lmi@gnu.org; Wed, 05 Feb 2020 12:30:50 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45827) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izOVg-0003Dm-WF for lmi@nongnu.org; Wed, 05 Feb 2020 12:30:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1izOVf-0000XB-4Q for lmi@nongnu.org; Wed, 05 Feb 2020 12:30:44 -0500 Received: from sonic315-16.consmr.mail.bf2.yahoo.com ([74.6.134.126]:46646) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1izOVe-0008RD-0t for lmi@nongnu.org; Wed, 05 Feb 2020 12:30:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1580923838; bh=YxvrIQm026rGcHMCInFieAZNoPJB1LwqrCizrdu4DyY=; h=To:From:Subject:Date:References:From:Subject; b=Mm1qaUNs97Y2tK8DtW8+h9EC+gYYOqfWueKaAcmlZEmWizGau245ud2IksEjo44Eapqj8P3bzGqSC/WGfjpQ1ghanh3QUyxYwgHjk1jyntyfGMn14v2YzGzp4MzEwlQrVXZ0ByRccGfVAMREMcjNunMjIH2z7xz7OR7Gu75JCV3BXjZpemTq8L3IVSxAQbOKcweV57qdLqzlKZZie6vcxRoHhDHJ3ZDUVin3vOagn3Ovsa8ZQn48/adOc69o9n3cf70crE5XD8P3yI9lj0o4JXa4Xm7TXzmhuKn5ERFiCmw5EX5spXwQPDBXoYKLVKFXSqtH6cxrl/xquMLggqP0RQ== X-YMail-OSG: COpoi9AVM1kNvStL.UZd3GWL2aAFg26YZjxHBXn_kAJG0CN5_HcMjKQeCVlHsMD 86oGpWfpprEspTO1PwAXpDshq1_8CStQCEeWur7FxtX8m9ZsBBYuYOgptYevsVeqLEZqpbXWzptI QPhkFzOhOXjqsSVbegXwb6VzKcIwx8CJnSERWAiox28YmDlR.XfoPG6g0.jU9vij39Hv1BKy3b3F ij8eTWu80RxhHs7MiV9UBX7dtQORypLTVpapu0LCoGVtdjQeP4tWQy_INrV7wfkee1onuCp4uUZ7 VQiOb_Ep0f.BbUB.cihEVqxHdUlxt8GgvCcd1iToNmlDf_6mZy34t6t8ic43Ascd20xfoCa1F3NG 9XiEV_F1z9Bf1MqBbGuF9vD0QjpK4yZA54OvvfbdPhZboOvSlpWnzlOJ8TH3uKiHOb8mTDRCzsNi 1x7Smc.zg3I.baNpT3xmdi3D.uAeGzoNAYGyzVaCOc5KwFjcUjWrg_3aG6GOvz2jui94IwfsN4wK K8Iz.aHLW2r0qyvzZmWEkJrNh0QOsH_0ZAOKfVbA7j64_CLDZZhpCv5VPcCd4hv7y.xyqN3hC9Hv hXWCmOkdSFUVB2oXJWxlaWp2LOxLhi5eNhbPPfraTXn488Ju6NwLWZReIl7GfFB6T1iBWN9B_Gje bmmtmhkRbWzb2RKvtEDEIbQEm7amRjsRSDxVdAkhWRx3pQxlZlewNO7SpWK_Awss4IvD77qR.kZ4 pLaTn0AS.m3DZlX6VbGQ8DcVg3Ltg.jBBFlSdMWDNSV1A5SsKk6kgR5h_jrp3uCml5gz9W_tAHyt qN1MPcf.ZBsnpl0K7Dl_0EpD9m.DLnkF4XmYV15UaZzHfAzZDXdbaSMnAN8zcOMq863QTQ_yx5f. iqA0t4oQcM5.aa9V767zP8voJ8XrhVp5WAarYCEkW.0.mBzAYu8f7dAlzJwlCOKLysyd.R8Rc8_5 xw09NB5KwklKkj6d5HiI0Jgv1vMVPZp9dIwoVeev2EG1k0uyI.jmqEcaEyqwAsdx7nZEbHV1SgLa Qvg6H6pEH1PCAqD9qfSZp7OGPXdPCTKlFBBEzJIOu.XN2rNo09lEQLrCDaEmt.HFoDYtuoT5DwaE MaeiB.a0KaQyODRL58BrLSFozOO1KtXHRLBm8jKO3ig8vI3WyzceS4ptZ5cYES__RCm9rAzFo5Mn _cu75hLQtWDeKlfPrDNLpDV1wx.TLY_dsFSRc6fLBCRy5JFn5BlFiqvZHSFCx_8cWnHRY1jZGW9R 8uKQGnIohr_CK4ARuVw20WfGfA7Vvr0CR5n02J2C0GATx2QDEDgR4lyOhQ97jCgayRSaLTb3leaU shApSJ.atCaDYhhJFfRtLKpYvq1L0lNrA8jakfguqGYf1tK_SED2Pteej83UkESxnekv9E67zk0v 3hZXaA0pheKayDqa2CREx9g-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Wed, 5 Feb 2020 17:30:38 +0000 Received: by smtp415.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID df010d7ae9c8c989fac251b42e8ab737; Wed, 05 Feb 2020 17:30:36 +0000 (UTC) To: "Let me illustrate..." From: Greg Chicares Message-ID: Date: Wed, 5 Feb 2020 17:30:35 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit References: X-Mailer: WebService/1.1.15158 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_181) Content-Length: 4998 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.134.126 Subject: [lmi] yum: "Multilib version problems found." X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 17:30:46 -0000 It's a new year, so I'm trying again to build lmi on a redhat server. The steps are simple--just run the latest script in git as root: $cd /opt/lmi/src/lmi $sudo sh $git pull $ ./install_redhat.sh >/home/mm53451/rhlog_$(date -u +%Y%m%dT%H%MZ) 2>&1 ...but I quickly encounter the problem below: the command yum --assumeyes install ca-certificates curl nss-pem fails, apparently because I have multiple architectures installed. It seemed that running 'yum check' would be a good idea, or at least harmless, but after fifteen minutes it said nothing much: $ time yum check Loaded plugins: enabled_repos_upload, langpacks, package_upload, product-id, : search-disabled-repos, subscription-manager check all Uploading Enabled Repositories Report Loaded plugins: langpacks, product-id, subscription-manager real 15m26.591s user 13m51.752s sys 1m34.343s Then I tried package-cleanup --cleandupes but it said "No duplicates to remove". And 'yum list installed' says I have: nss-pem.i686 1.0.3-5.el7_6.1 @rhel-7-server-rpms nss-pem.x86_64 1.0.3-5.el7_6.1 @rhel-7-server-rpms which seem to be the same version. This line: Protected multilib versions: nss-pem-1.0.3-7.el7.x86_64 != nss-pem-1.0.3-5.el7_6.1.i686 in the error message seems to suggest that there's a 1.0.3-7 upgrade available for x86_64, but only a 1.0.3-5 upgrade for i686 I tried yum --assumeyes --exclude nss-pem.i686 install ca-certificates curl nss-pem but that gives the same sort of error message as without '--exclude'. Vadim--Are you familiar enough with rhel that you can immediately see how to fix this? If not, I'll go through the advice that's readily found with a web search. Here's the output of the original command: # Fix weird errors like "Problem with the SSL CA cert (path? access rights?)". yum --assumeyes install ca-certificates curl nss-pem + yum --assumeyes install ca-certificates curl nss-pem Loaded plugins: enabled_repos_upload, langpacks, package_upload, product-id, : search-disabled-repos, subscription-manager Resolving Dependencies --> Running transaction check ---> Package ca-certificates.noarch 0:2018.2.22-70.0.el7_5 will be updated ---> Package ca-certificates.noarch 0:2019.2.32-76.el7_7 will be an update ---> Package curl.x86_64 0:7.29.0-51.el7 will be updated ---> Package curl.x86_64 0:7.29.0-54.el7_7.1 will be an update --> Processing Dependency: libcurl = 7.29.0-54.el7_7.1 for package: curl-7.29.0-54.el7_7.1.x86_64 ---> Package nss-pem.x86_64 0:1.0.3-5.el7_6.1 will be updated ---> Package nss-pem.x86_64 0:1.0.3-7.el7 will be an update --> Running transaction check ---> Package libcurl.x86_64 0:7.29.0-51.el7 will be updated --> Processing Dependency: libcurl = 7.29.0-51.el7 for package: libcurl-devel-7.29.0-51.el7.x86_64 ---> Package libcurl.x86_64 0:7.29.0-54.el7_7.1 will be an update --> Processing Dependency: libssh2(x86-64) >= 1.8.0 for package: libcurl-7.29.0-54.el7_7.1.x86_64 --> Running transaction check ---> Package libcurl-devel.x86_64 0:7.29.0-51.el7 will be updated ---> Package libcurl-devel.x86_64 0:7.29.0-54.el7_7.1 will be an update ---> Package libssh2.x86_64 0:1.4.3-12.el7_6.2 will be updated ---> Package libssh2.x86_64 0:1.8.0-3.el7 will be an update --> Finished Dependency Resolution Error: Multilib version problems found. This often means that the root cause is something else and multilib version checking is just pointing out that there is a problem. Eg.: 1. You have an upgrade for nss-pem which is missing some dependency that another package requires. Yum is trying to solve this by installing an older version of nss-pem of the different architecture. If you exclude the bad architecture yum will tell you what the root cause is (which package requires what). You can try redoing the upgrade with --exclude nss-pem.otherarch ... this should give you an error message showing the root cause of the problem. 2. You have multiple architectures of nss-pem installed, but yum can only see an upgrade for one of those architectures. If you don't want/need both architectures anymore then you can remove the one with the missing update and everything will work. 3. You have duplicate versions of nss-pem installed already. You can use "yum check" to get yum show these errors. ...you can also use --setopt=protected_multilib=false to remove this checking, however this is almost never the correct thing to do as something else is very likely to go wrong (often causing much more problems). Protected multilib versions: nss-pem-1.0.3-7.el7.x86_64 != nss-pem-1.0.3-5.el7_6.1.i686 Uploading Enabled Repositories Report Loaded plugins: langpacks, product-id, subscription-manager From MAILER-DAEMON Wed Feb 05 12:39:31 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1izOeB-000076-Kt for mharc-lmi@gnu.org; Wed, 05 Feb 2020 12:39:31 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50334) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izOe9-00006y-7L for lmi@nongnu.org; Wed, 05 Feb 2020 12:39:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1izOe7-0003IY-RS for lmi@nongnu.org; Wed, 05 Feb 2020 12:39:28 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:37748 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1izOe7-000392-JO for lmi@nongnu.org; Wed, 05 Feb 2020 12:39:27 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1izOe5-0005qy-0V; Wed, 05 Feb 2020 18:39:25 +0100 Date: Wed, 5 Feb 2020 18:39:25 +0100 From: Vadim Zeitlin To: "Let me illustrate..." cc: Greg Chicares MIME-Version: 1.0 Content-Type: MULTIPART/SIGNED; protocol="application/pgp-signature"; micalg=pgp-sha1; BOUNDARY="4294967295-41-1580924365=:29216" References: In-Reply-To: X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.240.17.225 Subject: Re: [lmi] yum: "Multilib version problems found." X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 17:39:30 -0000 --4294967295-41-1580924365=:29216 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE On Wed, 5 Feb 2020 17:30:35 +0000 Greg Chicares wrote: GC> It's a new year, so I'm trying again to build lmi on a redhat server. Did this work last year? I.e. has anything changed or had you simply not tried doing it before? GC> The steps are simple--just run the latest script in git as root: GC> GC> $cd /opt/lmi/src/lmi GC> $sudo sh GC> $git pull GC> $ ./install_redhat.sh >/home/mm53451/rhlog_$(date -u +%Y%m%dT%H%MZ) 2>&1 GC> GC> ...but I quickly encounter the problem below: the command GC> yum --assumeyes install ca-certificates curl nss-pem GC> fails, apparently because I have multiple architectures installed. [...] GC> Vadim--Are you familiar enough with rhel that you can immediately GC> see how to fix this? No, unfortunately I don't really know much about multilib handling on RPM-based systems. I could try setting up a similar system here and experimenting with it, but GC> If not, I'll go through the advice that's readily found with a web GC> search. It looks like the advice is to install both 64- and 32-bit versions of the package, e.g. yum install nss-pem.{i686,x86_64} and this seems logical, at some level, but I also wonder why doesn't it do it automatically if this is all it needs. In any case, if this does work, I see no problem with updating the original command in install_redhat.sh to do it. Please let me know if it doesn't work and if you'd like me to do anything about this, VZ --4294967295-41-1580924365=:29216 Content-Type: APPLICATION/PGP-SIGNATURE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iEYEABECAAYFAl46/c0ACgkQBupB3k9sHoY+TQCgpu6o6fFXt7CWNTshWhX430h6 N74AmQHNh/QLyOEeKNK+aajLpt1V08P7 =XQ3h -----END PGP SIGNATURE----- --4294967295-41-1580924365=:29216-- From MAILER-DAEMON Wed Feb 05 16:24:46 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1izSAA-0008A0-JZ for mharc-lmi@gnu.org; Wed, 05 Feb 2020 16:24:46 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41783) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izSA7-00089f-DQ for lmi@nongnu.org; Wed, 05 Feb 2020 16:24:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1izSA6-0005AE-37 for lmi@nongnu.org; Wed, 05 Feb 2020 16:24:43 -0500 Received: from sonic307-5.consmr.mail.bf2.yahoo.com ([74.6.134.44]:41744) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1izSA5-00051p-PJ for lmi@nongnu.org; Wed, 05 Feb 2020 16:24:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1580937879; bh=OwfnJOpmzBPvNAc66z1KXI+NO38DeBn8PkQ8mcqKTps=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=WJtkNiJ42Te7VRpeEbE57sgCSlhFiDH9KRSJkNktaEqu7C2OjCAVNLFDXKXKCXyJt8PwjoCaLbh8k3rdHxdXny1O/f/F+kt7yTA79Gm2/9rxRI/lr7ecleEkZfR4q73X6tP4TDw5b4o+v8cR9G21I6tE4nDCB5FM6B7ZlSyxIa5L2NlweLuFEfQNREtn1pIuKUYYlMIM50XYk1NXypvPWgdaAu27gRoGFe9U5Bk7ccLuYw3mKM1g/aIXEmLD+2lZtL3yh4KO749mVNB66gPESksL8bUKPCrmXL9jS7G91pg23/9+Ms4818tD3h2ArPa2EeS4U/TQPQwaak3bp5xbHw== X-YMail-OSG: 3D5lu08VM1n.eLBFNbhASMGJ7JypxeGETFYqaDryx7bdST9xrW9fgIuZOvP2bD0 kuzKOads68KJDHPFupXOD0RTw1s7qZhxfF8DRqc4asBNXmSzfp1YjPEA5Etvl5J6YdbejQGdMbgZ ogG_XcrSRtmuapNVYW2755pBKjTEAQGKr5DNff_3sbz8_5w4AmC6afvssku_6MlUaRX4MWXEOGkn to5v0on.TS9oUfm6mRA9nYkku0kGcTQhAp2uDEKlDf6LM17Wscq_ZtOJ2zk_u0ut47EdF5llfcGG g9CCGKNpbRwT11h0zJdl0XZ03xjuhexQ7Ds5CwviNrZRjpOnpKAk1VkuI7v2dN_yI5lT7dauE1OO gEYRAzyZKhppjYKHLYBBAoAVNBAueWmzC5sbk9nsIToia4WR09nKXyCwP.PpQTFh2ohxQgwd9ed6 W5JZHTnB_ujaRpSsIAnpFkPNm_7bVDaBjJ8RhoCYAjSzgabCwEgVMAohNoqwNSepV.RsS96y8Hnm 2AnMr0e6Q2m58EAbBq9rQ1VMPpDc6NhRBuKGVGb3OCUgq1Y_a.B6P8D27hQzSmTCtQTWmqjPbO2L h2e0e_ufLMfjovElHiRlxAepNGegKkiZ7XBBZbabAXT_bv0DGCHGUWmShU4cDud3qWGrOApa3EO5 aeJ92fCqmG31ZTTUyah5Kk5F4sSD7hWi166d_LJX9Lh.gL04FUUgnYC91f6p6v3ahZE3JsZ6pthS 0xkhzVW4DfEGvXt8avzcnDL9k48QmXoKJ3RZPBFjCGC1q26jmUwy5izLXqKctacp2XIFEhLRNnOQ kP6JCBVzHZyuroYn6Xo0HVwtKDOmQ.G7W2uQvkXQvyJY0OnT5J5_a4ergtYyK8lbgrDuSM_Mzjul ObhcKCJlbhaHsuzi7zaKsSoyZGWSD2Zd7KKo.WrHIhpYndKHG4i.mpBlZBo9E5Jdfm3.pUhmcp7u _dn_Ui482quYgYd_nxsEst7CgQE4RVLv2Dp0Fp75s_l.caZx2vyuIK4WMy909_Dbq2GNcZWlJAJ0 9nRn.gtbJqe.e0zucbW119g3ZvJZlvcKTbv0rEpEzE2T5Tjn4qdYnnzwXWuh7mZr4hOde1tRWEOm 46LqU0WhKpuG6lEVeUQx8y0NNAq5lweu21UxAxDhOkWcCVwv1__c0Wxkz8mRlG4Xh7cKA7etWoRf eje9HIKmc17FJFj4HkIAgzNLcMlJl2y4pDE1AK.F1AaTuk.DdK.mk_Lg_olacYX8zjiuDvvE0Ool S4r1hyNnkRz5vkkUMV6j6MxuLJ7v81WwKm.txWwLOxD4r1tPUxsjvMU6OiBK_fXLHF0r2Px2JgIv 8eOsGVU_VRDZBx4Zw8GQyesktBn7_b.V_bDp4fmHKVzY3lBI0kawkwuO7ilwNuf.Ux43STqurmgB EyYwAfnUEe6o39891BA7OOHy2__Q- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Wed, 5 Feb 2020 21:24:39 +0000 Received: by smtp417.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d275128514b13244dc0077d72b5eebcc; Wed, 05 Feb 2020 21:24:36 +0000 (UTC) To: "Let me illustrate..." References: From: Greg Chicares Message-ID: Date: Wed, 5 Feb 2020 21:24:35 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.15185 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_181) Content-Length: 3947 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.134.44 Subject: Re: [lmi] yum: "Multilib version problems found." X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 21:24:45 -0000 On 2020-02-05 17:39, Vadim Zeitlin wrote: > On Wed, 5 Feb 2020 17:30:35 +0000 Greg Chicares wrote: > > GC> It's a new year, so I'm trying again to build lmi on a redhat server. > > Did this work last year? I.e. has anything changed or had you simply not > tried doing it before? Short answer: It worked last year, and today I simply reinvoked the same commands that were still in zsh history from last October. More details: Instead of using a tmpfs for /srv, I've now formatted and mounted /srv/chroot to hold the debian chroot where we do the actual work (but today's failure occurs long before any chroot is created). And last year's work was only a proof of concept (IIRC, some msw code was built, and some tests were run, but I'm not sure we achieved a full production build). Although I tried to capture every useful step in shell scripts that reside in the lmi repository, along the way I took many experimental steps that were not immortalized in scripts. Thus, I can't say why we have any i686 code that isn't in a chroot: it might have been part of the prebuilt server we were given, or I might have installed multiarch stuff as part of an experiment that didn't work. > GC> The steps are simple--just run the latest script in git as root: > GC> > GC> $cd /opt/lmi/src/lmi > GC> $sudo sh > GC> $git pull > GC> $ ./install_redhat.sh >/home/mm53451/rhlog_$(date -u +%Y%m%dT%H%MZ) 2>&1 > GC> > GC> ...but I quickly encounter the problem below: the command > GC> yum --assumeyes install ca-certificates curl nss-pem > GC> fails, apparently because I have multiple architectures installed. > [...] > GC> Vadim--Are you familiar enough with rhel that you can immediately > GC> see how to fix this? > > No, unfortunately I don't really know much about multilib handling on > RPM-based systems. I could try setting up a similar system here and > experimenting with it, but I'd hesitate to waste your time that way. With your help, last year I created a centos chroot on my own computer, which is intended to simulate the redhat server; I'd try to duplicate the problem there first. I might find that all the i686 stuff in the redhat system (and, if present, in the centos chroot) is useless, and that the solution is to purge it. I suppose it's possible that rhel-7.6 is inherently a dual-arch system, and that purging the i686 parts might be harmful, but I really doubt that. > GC> If not, I'll go through the advice that's readily found with a web > GC> search. > > It looks like the advice is to install both 64- and 32-bit versions of the > package, e.g. > > yum install nss-pem.{i686,x86_64} > > and this seems logical, at some level, but I also wonder why doesn't it do > it automatically if this is all it needs. In any case, if this does work, I > see no problem with updating the original command in install_redhat.sh to > do it. I tried that, as two separate commands: yum install nss-pem.i686 yum install nss-pem.x86_64 and both failed with the same error message reported earlier. And I tried yum-complete-transaction but it said there were no incomplete transactions. Then I tried yum update nss-pem and everything seemed to work. In particular, whereas earlier I saw: nss-pem.i686 1.0.3-5.el7_6.1 @rhel-7-server-rpms nss-pem.x86_64 1.0.3-5.el7_6.1 @rhel-7-server-rpms now I have 1.0.3-7 for both. The conclusion seems to be that, when yum install PKG has already run successfully, yum update PKG && yum install PKG works, but yum install PKG fails. Searching the web, I find no indication that this should be true, while I do find indications that it should not be true, but for now at least I'm going to add this magical nonsense to the script. And it does indeed get farther: now I'm up to Failed to change to directory '/tmp': Permission denied which looks easier to debug than this 'yum' stuff. From MAILER-DAEMON Wed Feb 05 16:39:36 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1izSOW-0007ON-2z for mharc-lmi@gnu.org; Wed, 05 Feb 2020 16:39:36 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51201) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izSOS-0007MI-49 for lmi@nongnu.org; Wed, 05 Feb 2020 16:39:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1izSOP-0008TV-Rk for lmi@nongnu.org; Wed, 05 Feb 2020 16:39:31 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:40090 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1izSON-0008Jk-Tu for lmi@nongnu.org; Wed, 05 Feb 2020 16:39:29 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1izSOK-0004Qj-C5; Wed, 05 Feb 2020 22:39:24 +0100 Date: Wed, 5 Feb 2020 22:39:24 +0100 From: Vadim Zeitlin To: "Let me illustrate..." cc: Greg Chicares MIME-Version: 1.0 Content-Type: MULTIPART/SIGNED; protocol="application/pgp-signature"; micalg=pgp-sha1; BOUNDARY="4294967295-41-1580938764=:29216" References: In-Reply-To: X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.240.17.225 Subject: Re: [lmi] yum: "Multilib version problems found." X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 21:39:33 -0000 --4294967295-41-1580938764=:29216 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE On Wed, 5 Feb 2020 21:24:35 +0000 Greg Chicares wrote: GC> On 2020-02-05 17:39, Vadim Zeitlin wrote: [...] GC> > It looks like the advice is to install both 64- and 32-bit versions of the GC> > package, e.g. GC> > GC> > yum install nss-pem.{i686,x86_64} GC> > GC> > and this seems logical, at some level, but I also wonder why doesn't it do GC> > it automatically if this is all it needs. In any case, if this does work, I GC> > see no problem with updating the original command in install_redhat.sh to GC> > do it. GC> GC> I tried that, as two separate commands: GC> yum install nss-pem.i686 GC> yum install nss-pem.x86_64 GC> and both failed with the same error message reported earlier. I thought that doing it in a single command would tell yum to update them both at once, but I have completely forgotten about the "update" command, which also looks like a logical way to solve this problem. GC> And I tried GC> yum-complete-transaction GC> but it said there were no incomplete transactions. I think this could help if a transaction had been interrupted, but in this case it wasn't even started (successfully, at any rate), because of that "multilib problem", IIUC. GC> Then I tried GC> yum update nss-pem GC> and everything seemed to work. Glad to hear this! GC> And it does indeed get farther: now I'm up to GC> Failed to change to directory '/tmp': Permission denied GC> which looks easier to debug than this 'yum' stuff. Good luck, VZ --4294967295-41-1580938764=:29216 Content-Type: APPLICATION/PGP-SIGNATURE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iEYEABECAAYFAl47NgwACgkQBupB3k9sHobnBACfX0K0jGNd5VOS3ORtJCqR6FPT br8An0en+I+bl1pOf4oGzIIyyXwQbDlQ =MMzF -----END PGP SIGNATURE----- --4294967295-41-1580938764=:29216-- From MAILER-DAEMON Wed Feb 05 19:38:55 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1izVC3-0006xu-8P for mharc-lmi@gnu.org; Wed, 05 Feb 2020 19:38:55 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35695) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izVBz-0006xf-VY for lmi@nongnu.org; Wed, 05 Feb 2020 19:38:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1izVBy-0007m2-Ij for lmi@nongnu.org; Wed, 05 Feb 2020 19:38:51 -0500 Received: from sonic301-4.consmr.mail.bf2.yahoo.com ([74.6.129.43]:40982) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1izVBx-0007VX-FU for lmi@nongnu.org; Wed, 05 Feb 2020 19:38:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1580949526; bh=6ICSHJLWJ36mEWo2qJ3DWDU7BgJ1SIbttwyxyPCFOT4=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=JEJtXWCQYepsYag//RrjhcPkONOszLDxrLPq4IdIKY2J6HWAuMNtcORkhCD5ZQbo9msvANEzasq5jdRFVY8n6iUug4qiRXi4xslB0skbKrvsRaE4mZpcpE8mDrtZYonyL2YmIGl0rVnqAqSYFLSHwIDWw91wFRF7e7ti7oa2S7lNYbxQL1XY2DY7cQeLd0VQXoSY9RBZBGpjl+DBhRgCYs5a8KfEI7Xd4G3FW+Bcam3okqLmrFldcVCqi68licDR9HjDIRqrBoIEos33W9BAQkXuOr9cTrFV1KBIEtWuKAVD/okrAKWyhui+MUEhGXMa5Pdh28nHoJJ3IovEF4BoqQ== X-YMail-OSG: 9FQTQRoVM1k018WOdV1ZBybTrjnoZcFAXC9M75UeJztJZajATwSZPLr_mmwPI2R ZoZ9tW.7oTTkR_8LMGVj9tgezjcU0rUr94LlWDzw2lMbio14ied9iYfOS_1MIrKVGZBc2zVvNd0q Ua.pOaS0RqS2PfJV2FUARrYZE0giJ1Q_yY7JUm_.sLfgCiip7cbs0Pcw6DliSf60SkN8j1nOZXeM WUbDQzMITzNkcNhKO4ozgGq_yUjJW2sGTyjRu4jmmDDaWa6WexbyahfnoqhUnzptlMeYDbMo7K7L o.7ld7QPhj_veUiuY2gD9haKSfxn6xwAgwaidppLo62r20KPsYoWizs.2.AMKam_wSGXyVv.pvga pFYADI8d5TMt.3AmslJvMZlxboRArwZSuqV24LiuVLSTxxh83Nn7D4y3vidZX23s7efV4cbMeinD KqL7q36eZaUSw9E90k195ABqIZSuVynPfKHNPryG5VxbSDXiJsth3c8vqlmMla.H2E5Y6jkAwT0f FAxzBzZ6O4DKA7Cws4SRAePivbOL.EbBuzuWbVNn6Be_ldKlkMt2Q3Knk3BITSow6v18EYZkFw83 m0y4u.K4hgWJWGF8l4QK_oYqnWs5Rhx9ZK71XtE1Ywhwd2xjpJzFEMAzMV80CgiOHAvEGo61io3X FQ_nlj9tkFKQ82IX9SaDKT7RNOTLs6yklAuV3I2sUr5.WZo45bcAYFR_VlZG4viexQNeJxC3BubS 8ZcGHgrqh13BiQubGubvk7YEArIkLNoTL4cZLThxfEaEeaq3iFPE8yEpG365t07nYf3u940I4WOR HDyQX3ibQIQ0H13APDbXAVGWYjQC9fM93nBXQyqcw8QDP96FE9fOlqHlpu7I6SXpxlZRpV1iLzRO 0EXROf5wsHAYQRmSqU.X2E23.wtI3mIQK1YPqk1l3SiRKGj4g6b9VHdDJG0JZWVkD4PC0C1QbhGG yLc.g6CORqOCH3Y3ebghT6NwjL25KLTYur8mZu.oGNe8Q46myF8SHo7b1PjLgl4kqUzFNxrjNJAv jXbi98a2aT8GfDZJ8o11X8g6SAoFAYA5EVD2.P1v52483ntasKCejLnSX9KLAzOtKkDPGMnI4sFV JtPUhP4MI1WcjKb4_TUClXGqpZvyQ9DzIu86uU262r93a0fxQ3WNuxRLheq8SmENflpK5rugHIf1 9k9jcKb2VUsdIKgNQ1qlaoOWbtR8orcVje3WQnKPgYGymIpO9YLEvuBB0c6wfxv7rk7ByrXHYUWq RidMIxj8BpaPTdyXfJX4gALBcwKwmuClHwx6f9Oj7DXm1Sk8Y8myHSlYrngyxLxNwGdVPp2XzFy5 RVyOS_g7s8JnEcr489LXy7vG.Ey6ad4W2YUsYQF_meN9YGgHSXc5QHVl9swADoXEzr265iCoOj2Q mUNHmzaXblms.prD9JcT1VYSm9A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Thu, 6 Feb 2020 00:38:46 +0000 Received: by smtp428.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 68e20762a60a5800f3857e2e7aac011d; Thu, 06 Feb 2020 00:38:44 +0000 (UTC) To: "Let me illustrate..." References: From: Greg Chicares Message-ID: <3f4e2a05-8c15-2cdc-e42a-46e763892731@sbcglobal.net> Date: Thu, 6 Feb 2020 00:38:42 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.15185 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_181) Content-Length: 2809 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.129.43 Subject: [lmi] When chsh doesn't work [Was: RHEL userid puzzlement] X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 00:38:53 -0000 On 2019-09-17 23:31, Greg Chicares wrote: > On 2019-09-11 13:03, Vadim Zeitlin wrote: [...'chsh' has no effect, and this command: sudo grep `whoami` /etc/passwd prints nothing...] >> This depends on the system configuration, /etc/passwd is just one of the >> possible sources of the user database and I guess this system uses >> something different, e.g. an LDAP or a NIS server. > > Indeed. I also tried chsh -s /bin/zsh `whoami` but, after typing my password, it said chsh: user [REDACTED] does not exist. The really weird thing is that 'chsh' lets me change the shell for the root user, although even as root I can't do that for my normal user. >> Otherwise, I can only recommend putting "exec zsh" (preferably after >> verifying that it's available!) in your ~/.bash_login, e.g. something like >> this: >> >> if hash zsh 2> /dev/null; then >> exec zsh -l >> fi > > Yup. That's the only convenient way. Others have had this > problem, and that's the answer that works: > https://stackoverflow.com/questions/33292541/how-do-i-change-my-default-shell-in-ubuntu-when-not-in-etc-passwd/33292612#33292612 Okay, there's no ~/.bash_login file, so I modified the existing ~/.bash_profile by adding exec /bin/zsh -l as its first line. That seems to work well enough. But I still get lots of environment variables that I don't want, including a full-page definition of $LS_COLORS, which seems to come from /etc/profile.d/colorls.sh How do I prevent those from being defined? I tried exec -c /bin/zsh but that leads to WARNING: terminal is not fully functional yet export TERM=xterm seems to fix that problem. However, 'env|less' still shows an empty LS_COLORS= and other unwanted variables like MANPATH=:/opt/puppetlabs/puppet/share/man QT_GRAPHICSSYSTEM_CHECKED=1 How did those get there? I've added unsetopt GLOBAL_RCS to ~/.zshrc, so no global zsh startup files should be read, except for /etc/zshenv which contains only comment lines. To thank you for reading this far, I'll tell an amusing story. I spent half an hour trying to figure out why sudo sh started /bin/sh even though I had changed root's default shell to zsh using chsh. (SPOILER a few lines below, in case it's not obvious.) I figured that I must have started zsh, because: echo $SHELL /bin/zsh and I was puzzled that this command: ps -p $$ insisted that I had actually run 'sh'. It turns out that I had memorized 'sudo sh' as the closest approximation to 'su' that I'm permitted to do on this server, so I thought I was in effect executing 'su'. Eventually I realized that I needed to add a 'z' in sudo sh if I wanted to start zsh as root. So now the Delete key no longer means "change case" in a root shell, which sounds like a small thing but actually makes me much more productive. From MAILER-DAEMON Fri Feb 07 07:39:04 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j02uV-0000X1-TO for mharc-lmi@gnu.org; Fri, 07 Feb 2020 07:39:03 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48206) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j02uT-0000WT-Vs for lmi@nongnu.org; Fri, 07 Feb 2020 07:39:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j02uR-0004Mg-Uf for lmi@nongnu.org; Fri, 07 Feb 2020 07:39:01 -0500 Received: from sonic316-14.consmr.mail.bf2.yahoo.com ([74.6.130.124]:41788) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j02uR-0004IC-MM for lmi@nongnu.org; Fri, 07 Feb 2020 07:38:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1581079135; bh=HYcGVu4a3sOX1AYxItrRXT3sNpXCaGRASUzz9DeEUkk=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=BO/bt6AUKs+Fg9JBvknAgogFGjsO6H90J3hpst4n8Allw7FgMi9jQcvXwvmKrYr5bQDfuMA44RLt618X81LE4tXnLF1ZlUZnBmQXB/laOx0wlvoSURcBt6SPFrTI+orqbu2rQcKgtGObOYFzuVt5VuPWBDbMLK3e/86uh1+cEoaaHuSWnoDq/qrSyMOv++6DNSleLqRYDf5zf83j7lGZsJhY7vgdPPP11g1JMipRb8qUsSs2MNUbhGkub0WaWOW495rp4zdEzT47Z1D5KFHT7KpGunAXUTRI9vlH47P9o/sc4IyfOzq6ce2nUGw4tewlQTIqY5r6lAJkilSV+7Eulw== X-YMail-OSG: mBUC.w0VM1nc6_jbv5gBp_dJ.qVNbKSYRNisCY5bSVnuCC_MH8GF_NnN3Wk5yx6 bM9Torc_ljQp68dLCHbI8ImAPs7nM4IJ3X1TwXAw6IEkMNzcm_McbRPksoOSbTfiie5h9IVBrG5U Xd7GlNOqOa2vRFhdDmYhWs8GbLLg8bHrOQLSzZhfBu4cRhOptcCvFQvdR6eLLCXBo1i7C9NJKMdJ WVBogKa2smMelXMAQhfHrfjsgr_KeszRi.pmg0yfkSB5sl_s.9WOV14bLs08HF_tTFuyCqilsw6Q nl_121kXkJFmh08zFG0BpFeC81Y_FKpwmDxU149gOqfqKIZvLK.CVFkx9joXE87zXqIavpYJGnyi SKHRAJZRI.p44i.6rox2kT6O4dzNvsu_dgzD4oivSW1dgo5qOOMcTjJty2KaBPS7RLAUWvsyc02m Jw5I2uFPecwumxUw5qwlvpdTxVtsAbxg1qjXrjXHRYiRjl9g.M.XT5Iv9Xi48lCG.7xJVTRMg8H. 8V81IMayZGyvQSOQznMq9WIOODL12zxFwvK1sQTANo9IqhpfERpNX0vK1E7XoiugcmOlY9Rs.e94 t.BeFnoEATOhg58pouBLRrn1iuNq0QgsKDzJQ0wguJW1Yf9_wYfcu.ww1d4ye5BJyZaie1vURdkE U.osC4frgypTsN0VFrOR9HV25lOnXB5vfgOfZFAnQnjrr3tbI0upRC3Nw13uPZ61gMB1DjrcnOFY c5Tr7_r0lgdcHcs0Ky7aL896Wh4AWqkvAybOADrGPtHr0gZ02NbA0Pe0.pT6WuuXpoT6mjfqsuTt BduqVGiztmRQ3qmbcWcijYvzjZqB3Q8Lg4PwsKoUJx52utrQtRGvhr6kvRVm7VRvd2QJfriwlWBU alUy6vVdK.UGWZD07YRKmmgBXzFNnYd5kEEUbPhg0O1wjSDxfK6mCm30wdzm11.hebEI.2tHWEwW bT4ve.gIV6Nrum_x6q_Eti_WT_MSkmFSCiOWr0VS.HXoEi1l3tyQnG.rgdlMbn.Vg3kFYZ5VuCjv S3hdk2CLgfXrjxOZ2PuqmYdnOaGe4_Nzr2_PITlamycixsa.H0WHTn_vv09lIosfvMAiVpZWAiqO MXRZ37Lbq3iyKwTW6DjqOH.tK1.oe5UZvxyvuWD13E42qf_eq3VOHT_UF_i6hG3xMEUww.JA3FGd _2gwx_jzHa40L_2AL9.zLYorZdVmFuK8x7QjWlPQldYl8oboUGTnikY4ipx7.Q3_fgNKpsW7isYW y.FztRCCoVzn2Wuba7G5EzzKnirLnVcYu0Yt7mSHianPjUHyxCoBcrHBrCROLVmOakxxMHxyAXZc Gok4PV0ZAL6UMNzIw1h5J1Ep1_97psaw_DId9zlE00X21wTUvrHQksTjdOIYQekAL4L.VT2awjDz 9AAqm94N.YrVzI4tXk0g- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Fri, 7 Feb 2020 12:38:55 +0000 Received: by smtp416.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e5fcbf5f452bc078ef8009382486066d; Fri, 07 Feb 2020 12:38:52 +0000 (UTC) To: lmi@nongnu.org References: <20200205151607.18069.39206@vcs0.savannah.gnu.org> <20200205151608.5098B21049@vcs0.savannah.gnu.org> From: Greg Chicares Message-ID: Date: Fri, 7 Feb 2020 12:38:51 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.15185 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_181) Content-Length: 1796 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.130.124 Subject: Re: [lmi] [lmi-commits] master 4eca5fa 1/3: Suppress a redhat nuisance X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 12:39:03 -0000 On 2020-02-05 15:24, Vadim Zeitlin wrote: > On Wed, 5 Feb 2020 10:16:08 -0500 (EST) Greg Chicares wrote: [...] > GC> +# Suppress a nuisance: rh-based distributions provide a default > GC> +# zsh logout file that clears the screen. > GC> +sed -e'/^[^#]/s/^/# SUPPRESSED # /' -i /srv/chroot/centos7lmi/etc/zlogout > > Just in case it can be useful: you could also add the following line to > your ~/.zlogout file (creating it if necessary): > > unsetopt GLOBAL_RCS > > This would inhibit /etc/zlogout (or /etc/zsh/zlogout or whatever) from > being read. > > Of course, you could also unset GLOBAL_RCS earlier if you don't want to > use /etc/z{profile,shrc,login} neither, but doing it in ~/.zlogout is the > least disruptive way to skip /etc/zlogout. Here's an emphatic variation: sh -c 'exec env -i TERM=$TERM /bin/zsh -o NO_GLOBAL_RCS' I considered making that the first line of ~/.bash_profile in lieu of exec /bin/zsh -l but I fear that it might be too extreme. I certainly needed to pass $TERM through. I suspect I might also need things like XDG_SESSION_ID USER LOGNAME HOME which are missing after the 'env -i' invocation above. It looks like redhat has added a lot of superfluous stuff in their /etc/z* startup files, but I don't want to spend time going through everything in detail. For example, when in /etc/zprofile I see: # Make /etc/profile happier, and have possible ~/.zshenv options like # NOMATCH ignored. # emulate -L ksh ... source /etc/profile I content myself with running 'emulate' at the command line to make sure that ksh emulation was indeed localized in that file. Instead of trying to suppress zsh startup files, I'll just clean up after them by unsetting variables that seem clearly needless. From MAILER-DAEMON Sat Feb 08 18:32:53 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j0Zan-0002dL-5c for mharc-lmi@gnu.org; Sat, 08 Feb 2020 18:32:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37861) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j0Zaj-0002cJ-AU for lmi@nongnu.org; Sat, 08 Feb 2020 18:32:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j0Zah-00058m-NS for lmi@nongnu.org; Sat, 08 Feb 2020 18:32:49 -0500 Received: from sonic316-15.consmr.mail.bf2.yahoo.com ([74.6.130.125]:35690) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j0Zah-00055t-E6 for lmi@nongnu.org; Sat, 08 Feb 2020 18:32:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1581204764; bh=6TuydURtBg4ehaMoSaw8U8yPkRrsm2qzs0zGaXhu6BQ=; h=From:To:Subject:Date:References:From:Subject; b=KBGo1/Am6jKdfxqU9t6eE38B6mEQ0/5fPFpOm823YWEg6Og/5C+IyiVp51AD0CzzyGgJs3l+Qi0AmxRViCGYJm0Uj2as+cyxou6p83cyAbEhcsyVodcMgn3doBhmT7681bs1SNeNL6fYBYEIxf3Cs8xsT0Q0CbMsmeiohw5xjZN/dC3ZR0TvL4K3Hd1DGnO20muZn/fwalX4qlVKlpzCea5wg7sP7XqALBdeOgPz8qoEl5X9z68EMfMUHiGcevqYhplGYFxDgPUHQjluGvnNAnXAaHcJwtuf9ReayIhe173yWWgrPFtXYvF6DuJJnXXDXM3Peyhnk1n/95IACEXa6g== X-YMail-OSG: aM4JBSgVM1ktcIfZx0PElBCULZceOH6k7KTsi2mi0_u8uNC.ET._i1QOzOjprU3 0LvPiS4vK4af9C_0cZAnUgj8fSj6jLWLVIB2Up.gCOjbSmJ1TmPFeOYG4s6vUN12YtinHOHvLUVP r1VJ96z7jFkbvvF7ba48p46FDbtgzZaq3K9Ln8.l0HD0YhuxJe08SRxwoEEi3lfbuEQSOen19i0L nbivT_X2nYg6TsnuWnr_vuCIu3Lg0BlOJ0so.Kmqq8ahfOC0GEtOLtu1rgZWDnIPuUHJ_zZPZoKq Jck50toNPsh8cmPH04tFBz9TrJfkS5QE5mAudtLKgmxyUG6e9fc.l0ogCak_nlT7nfjTeoZqc602 lVb9jxwVOfAoyQRepHi4Qm45w5Nt5uG7Yzyp_zvYXsdOozT9Dq9NZCOODYSPs_52sCfoefWgoulG 9fJRafJhE1.F79cHo4pCbYyGYq7qYwmUyAQFwXsXs0eqwUbrhI1MlKfPTlu5JiqLlodNicMV36aN 8O08zRfq.AUFS9Fd3UeYong5xV23OzzGVmTsZQTjH4eWNa02pgThp827lUEfJx_F2ZSVCA9ne_7U G_NEjJBrKNzoNWj5GVaoS0F.QDyVfzzK03E.k2tcX5uKd.JFoYndCyizrR_OdXbbP5uAvQRtd2Hu vjDqf9dMd5iZ4eDf.AGCE2g34oi6DIcGwMfbLP3JfIzPGHFkaZB9xM4J54rrxkvTeUPNy4Hf7ANz 9Yz_tJpMjYP3Jd19bGwU_wHfP_1RDO5My6q1ydQCXfAAwqEucKEUtnh6wwQCcw7MNvrsjv7lK2yo 5RjyB9SY_aq9VFu331cWWyT9vEcJnoXsFEPBy1Vbpf8KmJOMpYXzxSBQC34Yc0y_holisSBFNhsl 7CAfdVR5A54Hp0BFLR_Fj9aVscbiqm26cGmtn5Mcc98Y0zZEEAXSjVYGm9qnANCNkBUcEuG3k17b FeVeeH.f1RiCR08KYO_3135bZo7jebKh.n0ki0hBJog8aj6P4pdCAixf2kL9OLVkKQnn.RP5nsLE NUflw6sjfFDq90dWFKCmtmwu.gFHmh69E_jbNhxF8h26_EjpN_x42TKtpAVxLGh9PvTg_vL3az2W Ml49LnnGs.N22ndPUGkmWO1XDXsYWJxEP5cknBj2Y9qQLcni4o2m4BhK8e0a5lzD2HYJVpSR5rWc yPughSZ..JsWDB9_N7pWDwv5CL0y7eLVaQCwEdEK2bq23ulORO9mr1j01LSoU5fypIUKKXola0wu 1a8B4CGRYszmy5pPkyCVrPVsQCPnfFvqksVJxmEFmUsiWgEl17UGRVspVPkHPx9d0.rXQSc1Reqr XeVal6XqEymlHQBRK4y2NN6P2WzVr2g01lydk0lKc0PO41CyYuBt0ExfbJWXnNZc06o8NolnzGvQ RjBbr2GTZzHWzGjqMTrIT2A6yNw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Sat, 8 Feb 2020 23:32:44 +0000 Received: by smtp423.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8577bfefbbef40fc0cebbf655780c1c9; Sat, 08 Feb 2020 23:32:41 +0000 (UTC) From: Greg Chicares To: "Let me illustrate..." Message-ID: <84a36faf-8c21-21c3-0003-c42dbada70c2@sbcglobal.net> Date: Sat, 8 Feb 2020 23:32:39 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable References: <84a36faf-8c21-21c3-0003-c42dbada70c2.ref@sbcglobal.net> X-Mailer: WebService/1.1.15199 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_181) Content-Length: 6536 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.130.125 Subject: [lmi] chroot's '/' must not have 0700 perms X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2020 23:32:52 -0000 [Posted for historical reasons. The problem may already be resolved.] I tried this, which worked before (I'm sure of that, because these commands were recalled from shell history that predates this problem): /opt/lmi/src/lmi[0]$cd /opt/lmi/src/lmi /opt/lmi/src/lmi[0]$sudo sh REDACTED/opt/lmi/src/lmi$ ./install_redhat.sh >/home/REDACTED_USER/rhlog_= $(date -u +%Y%m%dT%H%MZ) 2>&1 ["REDACTED_USER" is the name of my account on this redhat server; I've redacted literal occurrences of the name, and confirmed that it matches the ${NORMAL_USER} variable] Now, everything seems to work up to the last line here quoted from that script: schroot --chroot=3D${CHRTNAME} --user=3Droot --directory=3D/tmp ./lmi_set= up_20.sh schroot --chroot=3D${CHRTNAME} --user=3Droot --directory=3D/tmp ./lmi_set= up_21.sh # sudo -u "${NORMAL_USER}" ./lmi_setup_30.sh schroot --chroot=3D${CHRTNAME} --user=3D"${NORMAL_USER}" --directory=3D/t= mp ./lmi_setup_40.sh The schroot commands with '--user=3Droot' succeed, but the one with '--user=3D"${NORMAL_USER}"' fails: schroot --chroot=3D${CHRTNAME} --user=3D"${NORMAL_USER}" --directory=3D/t= mp ./lmi_setup_40.sh + schroot --chroot=3Dlmi_bullseye_1 --user=3DREDACTED_USER --directory=3D= /tmp ./lmi_setup_40.sh E: Failed to change to directory =E2=80=98/tmp=E2=80=99: Permission denie= d I: The directory does not exist inside the chroot. Use the --directory o= ption to run the command in a different directory. The debian chroot is, as expected, fully functional at this point. (Configuring 'wine' and 'git' would be the next scripted steps, but the debian system is complete.) Stepping back, I try to reproduce the problem while signed in as my normal user, outside the chroot: /home/REDACTED_USER[0]$schroot --chroot=3Dlmi_bullseye_1 --user=3DREDACTE= D_USER --directory=3D/tmp E: Failed to change to directory '/tmp': Permission denied I: The directory does not exist inside the chroot. Use the --directory o= ption to run the command in a different directory. /home/REDACTED_USER[2]$ls -ld /srv/chroot/lmi_bullseye_1/tmp ls: cannot access /srv/chroot/lmi_bullseye_1/tmp: Permission denied /home/REDACTED_USER[2]$sudo ls -ld /srv/chroot/lmi_bullseye_1/tmp drwxrwxrwt 3 root root 4096 Feb 5 16:15 /srv/chroot/lmi_bullseye_1/tmp That rules out any problem with the lmi scripts. On my debian machine, the chroot's /tmp permissions are the same: /home/greg[0]$ls -ld /srv/chroot/bullseye0/tmp=20 drwxrwxrwt 9 root root 4096 Feb 7 13:28 /srv/chroot/bullseye0/tmp but the schroot command succeeds (and the high inode number for '/' demonstrates that I have successfully entered the chroot): /home/greg[0]$schroot --chroot=3Dchroot:bullseye0 --user=3D`whoami` --dir= ectory=3D/tmp /tmp[0]$ls -di / 786435 / Back on the redhat server, I log into the chroot, and examine its /etc/passwd . As expected, my normal user is present, with exactly the same name, uid, and gid as on the redhat base system. Approaching the problem from a different angle, I compared the current log to one from 2019-10-10. They're substantially identical through the failing 'schroot' command, and that command itself is exactly identical in both. Both have the same version of 'schroot': Package schroot-1.6.10-7.el7.x86_64 already installed and latest versio= n Could there be some difference in the logs that actually is important but seems not to be? Ignoring - timestamps, which naturally must differ - slightly newer versions of some debian packages resulting from apt-get dist-upgrade - "Download is performed unsandboxed..."[1], which seems benign we see (lmi commit 79d1e7377 of 2019-10-10T23:21:10+00:00) that both 'users' and 'groups' were double-quoted in the old log 'rhlog_20191010T1303Z' (about ten hours before commit 79d1e7377). The old log shows the schroot command succeeding. However, reinserting the double quotes results in this on the server: schroot --chroot=3Dchroot:bullseye1 --user=3D`whoami` --directory=3D/tm= p E: Access not authorised I: You do not have permission to access the schroot service. I: This failure will be reported. whereas reverting (removing the double quotes) results in: E: Failed to change to directory '/tmp': Permission denied I: The directory does not exist inside the chroot. Use the --directory option to run the command in a different directory. The 79d1e7377 commit message says: Prefixing that failing command with 'sudo' makes it work as expected. However: sudo schroot --chroot=3Dchroot:bullseye1 --user=3DREDACTED --directory=3D= /tmp produces the same "...'/tmp': Permission denied" outcome. Taking a completely different approach...a web search for the error message leads to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D876703 | What are the permissions on the root directory of the chroot? redhat machine: sudo ls -ld /srv/chroot/lmi_bullseye_1 drwx------ 18 root root 4096 Feb 5 16:12 /srv/chroot/lmi_bullseye_1 debian machine: $ls -ld /srv/chroot/bullseye0/ =20 drwxr-xr-x 18 root root 4096 Sep 12 23:02 /srv/chroot/bullseye0/ so we want chmod 755: $stat -c '%a %A %U %G %n' /srv/chroot/bullseye0 755 drwxr-xr-x root root /srv/chroot/bullseye0 Testing: /home/REDACTED[0]$sudo stat -c '%a %n' /srv/chroot/lmi_bullseye_1/tmp 1777 /srv/chroot/lmi_bullseye_1/tmp /home/REDACTED[0]$sudo stat -c '%a %n' /srv/chroot/lmi_bullseye_1/ 700 /srv/chroot/lmi_bullseye_1/ /home/REDACTED[0]$sudo chmod 0755 /srv/chroot/lmi_bullseye_1/ /home/REDACTED[0]$sudo stat -c '%a %n' /srv/chroot/lmi_bullseye_1/ 755 /srv/chroot/lmi_bullseye_1/ /home/REDACTED[0]$sudo ls -ld /srv/chroot/lmi_bullseye_1/ drwxr-xr-x 18 root root 4096 Feb 5 16:12 /srv/chroot/lmi_bullseye_1/ /home/REDACTED[0]$ /home/REDACTED[0]$schroot --chroot=3Dlmi_bullseye_1 --user=3D`whoami` --d= irectory=3D/tmp REDACTED@ALSO_REDACTED:/tmp$ Now I'll update the build-everything script and run it again. --------- [1] "Download is performed unsandboxed..." This report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D930667 was closed because the problem seems to be permissions rather than 'apt'. Observe: /home/greg[0]$cat /etc/debian_version=20 10.2 /home/greg[0]$ls -ld /var/lib/apt/lists/partial=20 drwx------ 2 _apt root 4096 Jan 26 23:06 /var/lib/apt/lists/partial /home/greg[0]$ls -ld /var/lib/apt/lists =20 drwxr-xr-x 4 root root 4096 Jan 26 23:06 /var/lib/apt/lists Perhaps /var/lib/apt/lists/ should be owned by '_apt'. See: https://groups.google.com/forum/#!topic/linux.debian.user/sHhDsvTkxgQ From MAILER-DAEMON Wed Feb 12 18:43:56 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j21fg-0006jQ-13 for mharc-lmi@gnu.org; Wed, 12 Feb 2020 18:43:56 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59458) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j21fc-0006j5-Mg for lmi@nongnu.org; Wed, 12 Feb 2020 18:43:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j21fb-0005vr-Oo for lmi@nongnu.org; Wed, 12 Feb 2020 18:43:52 -0500 Received: from sonic316-15.consmr.mail.bf2.yahoo.com ([74.6.130.125]:40388) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j21fb-0005sw-FZ for lmi@nongnu.org; Wed, 12 Feb 2020 18:43:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1581551028; bh=I/8V0Ms6JdWydmIxxtIDehdBQe58HTQFcdeFKyRm9Nk=; h=Subject:From:To:References:Date:In-Reply-To:From:Subject; b=Jy/oPJinOT+vSKcT6OZqX2KZUguMTJ9U09XiNLALwbU4jlE3qvsa4bJC8FslCnKhrqoRjW5i6SPsHWXqZg3OhjMTorA4gTE43/jk316XsDaA/tY179LJcP2Ulh4QS1PhmOzPlgSjQ/WUlyk2VkcwzjvYmE3+cZ+X4g/G+oKJQIUZUNl41HqZFnzwkofnvjj7j+NzvofubocUg0coUOcSdot2QjxNbhQ+MHvNmcNxuiPR32fraSdo85vY/cnZ4jorFnZZIEYiIJfPgnuoHKdRNng8Oq9bKGjG201lLfI8Ij6JbogRCU5daUEG27aLGMT1MOpDbmW8tU4zdYfSlIrCEA== X-YMail-OSG: DNnz4ysVM1llsPKG3kzgm2UFAdGyA39pYK6Q4h20qnFwSefwe4BY69sM.STQqnh UkCNOhUSgxVIZutYX7jUlYeh2H.gnu3EYG4A1tqGngtk4zT2ryVlSsvIAFQLzIjO1espuC3bal8d bt3P.NmqK7.Tv33_2RZou7.dfpXL7lTkXku0TH5W6lmg0Z2TLd2ScL3zVFry1xHlHm_enj9rWuE6 U.DiQGYnW6cFiq.Ivxub.0Mz7yU8aqrWPOH7CcOZV6KxgyBAiWd95pwjM67zbKWL4LgmwdduvM9u PPg6.JzJYdXha700pRaJ2xk8R8TyyygodENICkjo2nwYQh5MVbeMoTZ.VnDmflXVBKgm5opZEV5H RgWkmrvW5dkRSYpd4fTZuOsz_WmP8_Eu5U9eosl_Lymcj6lMe5kl2OmzMnJxV4OSx6nkmytS6qfe XzN3iXDrFasF9LkSOsUKYL4aCE4LFBMH01.DRAYXpqz4h3MC9PY1uQ4S5FG5vOnJFs6hELcgYK0f 4cKbi1sT44gFCDJlsW9Kz7Fg_JsVofKyA7Q2t8W46KKpQtI5wKMnmLeLykqTgVQlrjA7wAzQW5TU 8mjG2zEJh.FYDIbdrnMVx7bYmpYEM5GIbSN0Gvn9s6nV0YkFeW8spByH2kwj1aL_NW6HcpK.0..k CY_R7yJomPPQJiphcLxdMpc2TX.RSILPymi6nzyjm7YiJVfmSwEK42kIos1T_rbOjdtSAQ4dphvP zBmTQEJnXx3MrEBLrL5DCwKaAZ5AJWO7F1nqdep4Felx3Evurz.smMJd3BVQCI9_oDXk.lIDMW1M 2BUhoQvArOnK7ulBbvczwBaAlduz4QQimfXjgq48HOPQvfdZMZhvhWq40bbvbo_3ic2p2FEN7gq6 .llqvOGKxBRCNZ3qVrO3OoAhABdhU.9YgyEofukboh14WqLvQCDjaFaO.bQoWZcbLnmQ.747DVJN 5jfV8gILK9.qTbFFuuSrig8PU9xoE.Cdl.Rt04U55iNAM56DdNvIZ98u1hY5_NtOAhpA23ZfuDFN 7ZerWBtd3PZ6XIrglkEQBuFZ3wq1ORKTMo7AikXFfjxZ4HRHLLnkVaRFRQFV1fpypX.b1kSrDMWL kxjznLf8d7BGr04zei81o3v22lIVB0ITZYA.rpBl.AYa_yJylNbIJ_vipjH_psJmOphy0SodXyHg 9V1Z52ZVghR.dwb1NP3RiG4raGXndLJGYjabBukVrDjB45.pjd1Z_le9jFrCxGQb5e9sehkDWxfM pT_nvrbflkU6Sgs6W7bRGnQlez1LxoUxZflDiKAvSir1HRtXyiGTQ3LroT_8DvNmuf8pDaBL2sC. H_O0hGt44X4uJAyPOw8d63zeOntLOsGvqXVzT.hwrTvNjiBb_8McO7TtyJd4sYyzvhKjykGWOOaa hiCXPt1DG4icOYj2eEWYLycDBPPQ- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Wed, 12 Feb 2020 23:43:48 +0000 Received: by smtp404.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 92a420b0bc77dda26be2a2adb094f90a; Wed, 12 Feb 2020 23:43:46 +0000 (UTC) From: Greg Chicares To: "Let me illustrate..." References: <820b6c66-36fe-2fa5-d623-c684d8bdfbb5@sbcglobal.net> <251cf870-cba7-8539-8c62-938397b277a2@sbcglobal.net> Message-ID: <6508b27b-aaf4-8f3f-2e52-b8d6ec4d9ce3@sbcglobal.net> Date: Wed, 12 Feb 2020 23:43:45 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <251cf870-cba7-8539-8c62-938397b277a2@sbcglobal.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.15199 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_181) Content-Length: 1187 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.130.125 Subject: [lmi] zsh keybindings on remote redhat server [Was: Failed vim-mode .zshrc experiment] X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 23:43:54 -0000 On 2019-10-25 02:17, Greg Chicares wrote: [...] > My ~/.zshrc, for reasons similarly lost in the mists of time, contains: > > # These three seem to be set by default: > # bindkey '\e[3~' delete-char # Del > # bindkey '\e[H' beginning-of-line # Home > # bindkey '\e[F' end-of-line # End > > I think I might have needed those settings in the last century for cygwin, > and then commented them out when they seemed to have become unnecessary. > > Experimentally, I uncomment the bindings for {Home,End}, and now the > anomaly reported earlier seems to have vanished, for viins mode. Now I find that I need to uncomment the one for Del as well. Otherwise, when SSHing from a corporate laptop into a redhat server, pressing Del... - in viins mode: switches to vicmd mode - in vicmd mode: changes the case of the character under the cursor It's helpful to know the vim movement keys {hjkl} when moving from a real keyboard to a laptop where the normal arrow keys aren't located where my fingers expect. And it's nice to know that I can always get into vicmd mode and use 'x' to delete a character. But I really do want the usual non-alphabetic keys to behave naturally, too. From MAILER-DAEMON Wed Feb 12 19:37:43 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j22Vj-0002QH-5f for mharc-lmi@gnu.org; Wed, 12 Feb 2020 19:37:43 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39001) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j22Vg-0002Q8-Fe for lmi@nongnu.org; Wed, 12 Feb 2020 19:37:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j22Vf-0004gr-6O for lmi@nongnu.org; Wed, 12 Feb 2020 19:37:40 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:56146 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j22Ve-0004e3-V3 for lmi@nongnu.org; Wed, 12 Feb 2020 19:37:39 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j22Vb-0001Ho-JY; Thu, 13 Feb 2020 01:37:35 +0100 Date: Thu, 13 Feb 2020 01:37:35 +0100 From: Vadim Zeitlin To: "Let me illustrate..." cc: Greg Chicares MIME-Version: 1.0 Content-Type: MULTIPART/SIGNED; protocol="application/pgp-signature"; micalg=pgp-sha1; BOUNDARY="4294967295-41-1581554255=:29216" References: <820b6c66-36fe-2fa5-d623-c684d8bdfbb5@sbcglobal.net><251cf870-cba7-8539-8c62-938397b277a2@sbcglobal.net> <6508b27b-aaf4-8f3f-2e52-b8d6ec4d9ce3@sbcglobal.net> In-Reply-To: <6508b27b-aaf4-8f3f-2e52-b8d6ec4d9ce3@sbcglobal.net> X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.240.17.225 Subject: Re: [lmi] zsh keybindings on remote redhat server X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 00:37:41 -0000 --4294967295-41-1581554255=:29216 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE On Wed, 12 Feb 2020 23:43:45 +0000 Greg Chicares wrote: GC> On 2019-10-25 02:17, Greg Chicares wrote: GC> [...] GC> > My ~/.zshrc, for reasons similarly lost in the mists of time, contains: GC> > GC> > # These three seem to be set by default: GC> > # bindkey '\e[3~' delete-char # Del GC> > # bindkey '\e[H' beginning-of-line # Home GC> > # bindkey '\e[F' end-of-line # End GC> > GC> > I think I might have needed those settings in the last century for cygwin, GC> > and then commented them out when they seemed to have become unnecessary. GC> > GC> > Experimentally, I uncomment the bindings for {Home,End}, and now the GC> > anomaly reported earlier seems to have vanished, for viins mode. GC> Now I find that I need to uncomment the one for Del as well. GC> Otherwise, when SSHing from a corporate laptop into a redhat server, GC> pressing Del... GC> - in viins mode: switches to vicmd mode GC> - in vicmd mode: changes the case of the character under the cursor I am not sure why does this happen, but there are basically 2 variables here: the terminal and the terminfo database. And infocmp command should give you the information about both, as it shows the current terminal and "kdch1" capability value (which corresponds to the Del key). So it should be possible to debug this by comparing its output in the various cases. Hope this helps at least a little, VZ --4294967295-41-1581554255=:29216 Content-Type: APPLICATION/PGP-SIGNATURE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iEYEABECAAYFAl5Emk8ACgkQBupB3k9sHobJ6gCfZas66nXPf3CEbzAlTGlMBNN9 FWMAoKcYhyayUIZJ6s0+mlWu1OH7nv8r =7B7s -----END PGP SIGNATURE----- --4294967295-41-1581554255=:29216-- From MAILER-DAEMON Thu Feb 13 08:14:21 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j2EJx-00041C-IE for mharc-lmi@gnu.org; Thu, 13 Feb 2020 08:14:21 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46216) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j2EJu-0003xm-4W for lmi@nongnu.org; Thu, 13 Feb 2020 08:14:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j2EJs-0005l3-CE for lmi@nongnu.org; Thu, 13 Feb 2020 08:14:17 -0500 Received: from sonic307-4.consmr.mail.bf2.yahoo.com ([74.6.134.43]:37123) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j2EJr-0005kh-Lq for lmi@nongnu.org; Thu, 13 Feb 2020 08:14:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1581599653; bh=wyy5ZVkAde68zzpHBKdFAPnT3+PXVOK6Mlau7XG+OoA=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=FQhA4Ga0yDj2C1kjH4BSJPAi8ZtdLA0veXRzgDuSlRxaeLh47LS4K0EZntolDwGahFSSzExtjQY6ssRo4QgeuBhz/xzODteiHWY18L22nGQ4VcH94bVJtEO8xSkC+nNZ3kKGmxld9dx+7jHHqoecyf0eoj2hptI176zhHs5NiE4xnnOh9ZBwNVrJdmW6QJ887oO/P0bfTWlusir68AIN5ILtZ7H80dEZSe+u3AizuOmbGw88OcxB0iR77IzVsNklq7oTENAketcSTwlt5M0xQ6Mc8qLSREvNN6qz/8fyWjr+DyYb7KvM9PjO/1opzy2QMSLfNePlmutEeuUMVF+jnw== X-YMail-OSG: SNcuincVM1ntuzrdmEwGrxjWVqaThJi6jFV3.erCsQrx9d_nh27evzxU9VOHnMT qqWWeeFhIvvPfin5lRbOj7RT38EBnq84twc4SDkg1QxnvOHYIN7C.RKQXnhdf01b6iW2HsYr1nmE IX.d3oj4stZSjU8di8C85VcDJf8yUrd_54GdFHlGtkZA3xkTTWgSPa8kWHjDIc7IqHI9f1Hm_RBK HQ_J5GubGfDwhabFTH5tlHOvmvh0KvJbbo79z2_aLmrkid1KpmhNUhfvUwhBSDLe0bEAKrOa.vpQ 10.cWeq6n6sOSbkh_hNkb4cUrl2981u0gI5ed0BitZm3a1HtNfuKXYG3l.EvCh3KpKNd.R_Ttda0 iJIxd8QX4yFJQQo4CRlfw84BgUKxYNtrGWla0pnt4mZU6zYbxDZb9Mpp9V_EZcj8m9szyimE7N4j Wrd_7IDcyzyG6CviXD4zCoz7PZiDdtu.sRyNMWIpO.aKMC8JIkwhq4HpkNGUsRLoGA5rfF7FZ39t zT6Z24nWZh4JwvKyLT3_syiJBdxZKwvNHBuZcaI_xskqutFqB1YJltHmuQ2tXxL2HMhnouTPKuh5 t9quvsLvjjzu4_y9FfW7Cojq9i0uY6KOJQe2c55D5mtYus2Xyl5RuUV0H0bioPO.Ysyr4v1LR_LC H4jIFzcI1LQR57a1F2wzdQZQHoTILmIT01SAy.w_FKYfBotXifVQnTNGqbpBRt2PODhacBwPDqbK idOsa4tp_aq8KJ9WhrugjsfK0Oh2FrFwG4i4Dl_zk.iB3SRGnWA4lY__rWQghvGPflbdHNcqi4xM cRDr4rpk3nXb6W.dCNkNRWtXF6qYZBAu3ul9CnWJ2ynCxgpNeYfZsYW2ZLqzwaAOlunE.iPK5iV0 h7IN6bKfg28Pnd2EmcDFUgfSepIQHNoayXXTLN.SR8hgp7gk0bi3KX27i0HVmjn3ykLCDKL1iaR1 ukkcCL0t.wk9XOvaLRlLu8m1VxzlB2wLviZilO.2gLwRcnUhkiTyW528zkqvpK67Fq5KrM74b99C F4wVCXXNK202XcnRz.6bsLd0kJfDV4nbZEEb2pDB3xJa6ICROrRkfyhyEXAHPK7VOJf3UrZjiHHA P.cZNoFpgeDM.m8YBeR4dHGgMu8d8elSmcj6H65ZDi7.sQxwUJcig8SDrYwsp7o50PX1sJZ_baJ8 .v3d9oE9QYEY4wM0_ZdWojNo4rXhQpJp6zQb2XwpesCBvwnP8lixrocj5I4YMy3FyOstihiNRD6p YzrDK.eWsm32ssZONRtxZN1RjGzDbi0lmT2m26lw..Y3IdWa80xVYb1jwiIefVwlFl5lPHxWV81u zGm4bmv0RhORJXXVKH.fFQTCxSX5QeCfQnbc0Ugmq32BMbJoVsqo7A26D9obqVsw_TVSRXDt8t9_ pU1CD6mXVY.1On__Kt4CXed24pkc- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Thu, 13 Feb 2020 13:14:13 +0000 Received: by smtp431.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID cac5dcafce65c4a219b92017a145d06a; Thu, 13 Feb 2020 13:14:12 +0000 (UTC) To: "Let me illustrate..." References: <820b6c66-36fe-2fa5-d623-c684d8bdfbb5@sbcglobal.net> <251cf870-cba7-8539-8c62-938397b277a2@sbcglobal.net> <6508b27b-aaf4-8f3f-2e52-b8d6ec4d9ce3@sbcglobal.net> From: Greg Chicares Message-ID: Date: Thu, 13 Feb 2020 13:14:10 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.15199 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_181) Content-Length: 2732 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.134.43 Subject: Re: [lmi] zsh keybindings on remote redhat server X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 13:14:20 -0000 On 2020-02-13 00:37, Vadim Zeitlin wrote: > On Wed, 12 Feb 2020 23:43:45 +0000 Greg Chicares wrote: > > GC> On 2019-10-25 02:17, Greg Chicares wrote: [...need explicit 'bindkey '\e[3~' delete-char' in ~/.zshrc ...] > GC> Otherwise, when SSHing from a corporate laptop into a redhat server, > GC> pressing Del... > GC> - in viins mode: switches to vicmd mode > GC> - in vicmd mode: changes the case of the character under the cursor > > I am not sure why does this happen, SSHing into that server, without binding Del, I type: jjjjjjjjj ^ and use the arrow keys to position the cursor at the fifth of nine characters, then press Del. Result: jjjJJJjjj The reason is that transmitting '\e[3~' has this effect: '\e' enters vicmd mode '[' is consumed with no effect (it sets context for an ensuing command like '%', but here no ensuing command uses that context) '3' repeats the ensuing command three times '~' changes case so the case of three successive characters is changed. This behavior actually is logical. When zle receives this escape sequence... - first, it checks for a keybinding; finding none, - then it feeds the escape sequence to its vicmd parser, and in this case the sequence just happens to be interpretable as a series of vi commands. The same outcome is observed if I explicitly hit these keys: Esc, [, 3, ~ In zsh's default 'emacs' mode, I would have seen something like '^[[3~' echoed onto the screen, which I would sooner have recognized as the absence of a naively assumed keybinding. > but there are basically 2 variables > here: the terminal and the terminfo database. And infocmp command should > give you the information about both, as it shows the current terminal and > "kdch1" capability value (which corresponds to the Del key). So it should > be possible to debug this by comparing its output in the various cases. Thanks. I wrote the output of infocmp to a file, transferred it to my real computer, and did git diff --no-index ~/Downloads/infocmp.redhat =(infocmp) which shows that the files are largely identical. Developing that command was interesting in itself, because git diff --no-index ~/Downloads/infocmp.redhat <(infocmp) did not do what I wanted. I started to dig into the reasons why, but the lesson I'll retain is that =() works more robustly than the <() and >() forms of process substitution. For now at least, I think I've made the server usable enough, but I'll keep infocmp in mind if I encounter another troubling behavior. I do notice this difference: -kbs=\177 +kbs=^? which seems to shed some light a concurrent change I'm making to .zshrc in order to make Backspace work the same on both machines. From MAILER-DAEMON Thu Feb 13 09:34:35 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j2FZb-0007wO-IF for mharc-lmi@gnu.org; Thu, 13 Feb 2020 09:34:35 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58564) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j2FZZ-0007wF-Dd for lmi@nongnu.org; Thu, 13 Feb 2020 09:34:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j2FZY-0008UQ-0k for lmi@nongnu.org; Thu, 13 Feb 2020 09:34:33 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:36126 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j2FZX-0008PT-Oo for lmi@nongnu.org; Thu, 13 Feb 2020 09:34:31 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j2FZU-0000bS-Uv; Thu, 13 Feb 2020 15:34:29 +0100 Date: Thu, 13 Feb 2020 15:34:29 +0100 From: Vadim Zeitlin To: "Let me illustrate..." cc: Greg Chicares MIME-Version: 1.0 Content-Type: MULTIPART/SIGNED; protocol="application/pgp-signature"; micalg=pgp-sha1; BOUNDARY="4294967295-41-1581604469=:29216" References: <820b6c66-36fe-2fa5-d623-c684d8bdfbb5@sbcglobal.net><251cf870-cba7-8539-8c62-938397b277a2@sbcglobal.net><6508b27b-aaf4-8f3f-2e52-b8d6ec4d9ce3@sbcglobal.net> In-Reply-To: X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.240.17.225 Subject: Re: [lmi] zsh keybindings on remote redhat server X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 14:34:34 -0000 --4294967295-41-1581604469=:29216 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE On Thu, 13 Feb 2020 13:14:10 +0000 Greg Chicares wrote: GC> On 2020-02-13 00:37, Vadim Zeitlin wrote: GC> > On Wed, 12 Feb 2020 23:43:45 +0000 Greg Chicares wrote: GC> > GC> > GC> On 2019-10-25 02:17, Greg Chicares wrote: GC> GC> [...need explicit 'bindkey '\e[3~' delete-char' in ~/.zshrc ...] GC> GC> > GC> Otherwise, when SSHing from a corporate laptop into a redhat server, GC> > GC> pressing Del... GC> > GC> - in viins mode: switches to vicmd mode GC> > GC> - in vicmd mode: changes the case of the character under the cursor GC> > GC> > I am not sure why does this happen, Sorry, I've realized that I should have been more precise, as usual: what I meant to say was that I didn't know why the behaviour differed between the 2 machines. GC> SSHing into that server, without binding Del, I type: GC> jjjjjjjjj GC> ^ GC> and use the arrow keys to position the cursor at the fifth of nine characters, GC> then press Del. Result: GC> jjjJJJjjj GC> The reason is that transmitting '\e[3~' has this effect: GC> '\e' enters vicmd mode GC> '[' is consumed with no effect GC> (it sets context for an ensuing command like '%', but GC> here no ensuing command uses that context) GC> '3' repeats the ensuing command three times GC> '~' changes case GC> so the case of three successive characters is changed. So this is indeed absolutely correct, but still doesn't explain, to me, why do you need to bind the key explicitly in some configurations but not the others, especially... GC> Thanks. I wrote the output of infocmp to a file, transferred it to my GC> real computer, and did GC> git diff --no-index ~/Downloads/infocmp.redhat =(infocmp) GC> which shows that the files are largely identical. ... if there are no differences in terminfo. The only remaining explanation I have is that there is already bindkey in one of zsh startup files on the system where it works out of the box. In any case, practically speaking, I don't see any problem with having this bindkey in your .zshrc. I don't think there can be any other keys producing this code and even if it's redundant, there is no harm in doing it, it's not like it takes long to create or update a key binding, so it shouldn't have any effect on shell startup time or anything like that. Regards, VZ --4294967295-41-1581604469=:29216 Content-Type: APPLICATION/PGP-SIGNATURE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iEYEABECAAYFAl5FXnUACgkQBupB3k9sHoZnnwCfdaWJz0wyh8ZlxNCSdYe+T/C5 fKAAn0feCc3zmmDSWpScJqgT5WLpp1dS =B2nK -----END PGP SIGNATURE----- --4294967295-41-1581604469=:29216-- From MAILER-DAEMON Fri Feb 14 09:19:49 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j2bor-00063i-IW for mharc-lmi@gnu.org; Fri, 14 Feb 2020 09:19:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34674) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j2boo-00063Y-V0 for lmi@nongnu.org; Fri, 14 Feb 2020 09:19:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j2bon-0000tN-KE for lmi@nongnu.org; Fri, 14 Feb 2020 09:19:46 -0500 Received: from sonic316-14.consmr.mail.bf2.yahoo.com ([74.6.130.124]:40033) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j2bon-0000pz-9h for lmi@nongnu.org; Fri, 14 Feb 2020 09:19:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1581689981; bh=6vdPQI4y5MGmeALGKAspl0EM8h9FXc7aUkc6Q2/C2W4=; h=To:From:Subject:Date:References:From:Subject; b=IfnpW09WJPnr7olhsVT7uFL6y0oCHsD2l4KwEPRgXGn1KBxJZ5m288AYSvZav7nOZOVxlPNaR+vrKM9sllY/BLZXrizONjekp6cwd0eyKJwwcjOOwBPeCLtopD82asTiWdEqRliTbwt80gOjMEsGqXVXe32P38Gqs4UcSDxwQDtgCKQBNIS8zAr4DjdaOce/0zr7Il/Ojd7qgQk9JeFVuyGcoMGXI5MwKpCiVUkHLhmlRgDJ773jxILBkJjr+E/HF7frbN/WAY9ZfLZf4dWHWTcI7lQfUyuB/TvaS9vkfn2H5cuFL/sH877+MpfVaWQupy5vWmvcQv/Php78K35pyQ== X-YMail-OSG: 8F2tvskVM1nKL.U5C__ewNDchZFFHZrvIDCaEI7XNAaIR3jfKew9pynBPlb3_E9 _1yyoJfEtOeGQnneb_bXuNQGQKt.NAieZvbfrWSg1iewB38EkBh8TZzpvbY6xL2hHHnr8jWP.vCH CANoBwUNIi28acuY.g9Z2wBt7T4bmYehzqG8vxFdEUyJ245_pxoFt0jkXEK1mvMxcn7Mttmt3SoJ HHjEkOrRVWxHhaf62kj9g1F66csw5FH.61DKWNU.w_KOq6TdBflOCAvJe7l2iMUvAxIjRSJrQGrk slSNQudI.9nvyOFPWwBIM14T2zEeJVzgeIBfUJvgq4ST3sd_mXL6P3RblrJzwpWCBU4WzmklIjGN .D_OtIqACKWUmtjgWLzOYzNQq3HqkVbboMa9craQ8e9zauh5YOGF7gMgPd7yR3ZPDqpbhicIHEO. KW33OWJA5NJrbh90s8Xk7ukeiICz2VI8.N1Ne7tyuUY.88FYFb9B7gq0CgDx5JiGZ2VzdhBAhxla Ao_K0pwt.yPoHTO3Cnm.V62lwCknPfzrsGy7Rtk2OvY8xNlPKtU6flk0JiqWXjLlRFha9qsUZ4I0 VtospL5gCL9q1l3Mfb1l.wE87llJblh4gKtF2WdqRGF00uJjkIeTnASVlUWMDtsXP3kVnkWj2.9S O6BPGWI1Uu5rbbPqdq_ve_yxKc1r5L4vlBkHYlBO.P4SwCm2QZbkHH7uS6o8wOnigZY48fcNSJT5 ._xPZuwgXM71dXEcDdfqiUvncUZVx_XcBGEmjJ1VAdoLqIPSeZZOqiHSPIotzlfnTc0rKr_acaJj N90aoY_O_JecWhPhzrj9pyk4bi6ikmxtShuqcDT0ED5itk7dgfuPoklIWphQP9WeCXKpIZsurdzB miku67JlV4kC_8mHWnpNsXQ0pyOko8gBTVxZbSqdRR5ylI2R99jvJ.2SF9ngoG3ThKIXq3bZsqkt glha3.9pQBKCTDBCB64rxMiqCZO1j7obSncrOeWNjWO_RxeLqtJ0C0Hn16taNIs3PEnlJMpRwCQF VoRoGbE0QVEg6KpdQD.yaMGYpE6RYv3E7mxkk0Y9AR.ikBbPJq2Tz4JavpJzOIlpAwfdOqNXOKdC oZCxWmLZuj8JCXYZ9_424IeJtu3649OYQbo4sigPl3Umd8tG0fvShjgM8eLL4fHAbmdlHg6SaeUf LClpiVCbUpUoFoLPxCaaz_d6bVVV2Gu_IiqUhd7Ll1TOGvVIyOMbXpOMnBmVsArEgGDzguKZcgXz x1vxgQF7dXQXoePCAfcdMaNy3yfaddl3lOIW2hIpxXiYgIDwQUzZyl9l3Px_b42AA1COGAvy1p5j FqETGgzHkmXQ4kd29A9hYQjtabjtqH6rdyGsGzHAwlqf2oQT8e.WwZYMVek47cG06uBjE9qPXZSF znOmo53F7tMXHAeqN Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Fri, 14 Feb 2020 14:19:41 +0000 Received: by smtp429.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 04a8524b439900a85f678a32f4dc6b5b; Fri, 14 Feb 2020 14:19:37 +0000 (UTC) To: "Let me illustrate..." From: Greg Chicares Message-ID: Date: Fri, 14 Feb 2020 14:19:35 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit References: X-Mailer: WebService/1.1.15199 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_181) Content-Length: 3657 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.130.124 Subject: [lmi] Sharing files for two users X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 14:19:48 -0000 To build lmi for a particular corporation, Kim and I have access to a corporate RHEL server. This server is supposed to be dedicated to this sole purpose; it has a couple dozen other user accounts, but those are for individuals in corporate IT, and I've never seen them logged in. The corporation sets 'umask 077' in its corporate defaults; thus, if I build lmi, Kim can't see my binaries, and I'm trying to figure out how we can share files routinely. We're both sudoers, so we could just 'sudo su -' and run routinely as root, but of course that's an atrocious way to implement file sharing. I've successfully created an "lmi" group and added both our accounts to it. Our primary group is something like "default_user_group": the same group for both of us and apparently for other accounts, too. I figured it would make sense to change our primary GID to "lmi", but we don't have user-management privileges: we can't run 'useradd' or 'usermod'. That seems unfortunate: there is necessarily some proprietary product information on this server, and ideally it would be restricted to us two, because no one else has a need to see it (though that seems to have little practical significance, as every other user probably logs in only to perform superuser tasks anyway). I experimented with running newgrp - lmi which does let us change GID. I don't much like that, though, because it starts something that's like a subshell in that 'exit' returns to a "parent" shell, yet unlike a subshell in that $SHLVL is 1. OTOH, we're doing all our real work in a debian chroot, where we do have the power to run 'useradd' etc., so maybe I should just ignore the redhat base system's limitations and set the permissions we really want on the chroot. Recently I recreated that chroot, using the same scripts I had used last year, but found that I couldn't log in to the chroot as my normal user; lmi commit 6a4fa701dc of 20200208T23:24Z was a minimal workaround for that problem: Make sure chroot's root directory is world-readable diff --git a/install_redhat.sh b/install_redhat.sh [...] mkdir -p /srv/chroot/"${CHRTNAME}" debootstrap "${CODENAME}" /srv/chroot/"${CHRTNAME}" http://deb.debian.org/debian/ +# Make sure chroot's root directory is world-readable--see: +# https://lists.nongnu.org/archive/html/lmi/2020-02/msg00007.html +chmod 0755 /srv/chroot/"${CHRTNAME}" That enabled me to log in, but Kim still can't read the files I create in the chroot. Apparently the root cause is that the corporation has set 'umask 077' in etc/profile customizations. As a next step, I was thinking of replacing the above commit with: +# Make directories and files created by this script available to other users. +umask 022 mkdir -p /srv/chroot/"${CHRTNAME}" debootstrap "${CODENAME}" /srv/chroot/"${CHRTNAME}" http://deb.debian.org/debian/ which seems like a good idea: - we're using 'schroot', in whose '.conf' file we can restrict the chroot to our two user accounts only - any file in this chroot should always be shared by both of us Probably 'umask 027' would be even better. The last octal digit seems irrelevant if all users share the same primary GID, so I'd prefer to make the "lmi" group our GID at least within the chroot. One way to do that is apparently to execute chmod 2750 on the chroot's root directory (some regard any use of the setgid bit as a security concern, but here my goal is to set the chroot's GID to a group with the lowest privileges and the fewest members). Another way, since /srv/chroot is a separate HDD, is to use the 'grpid' mount flag. Does one of those approaches seem preferable to the other? From MAILER-DAEMON Fri Feb 14 12:28:48 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j2elk-0003Xg-BB for mharc-lmi@gnu.org; Fri, 14 Feb 2020 12:28:48 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51310) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j2elg-0003XR-Nl for lmi@nongnu.org; Fri, 14 Feb 2020 12:28:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j2ele-0002kW-UG for lmi@nongnu.org; Fri, 14 Feb 2020 12:28:44 -0500 Received: from mail.frols.com ([82.232.97.23]:52473) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j2ele-0001lc-Iz for lmi@nongnu.org; Fri, 14 Feb 2020 12:28:42 -0500 Received: from 184.143.14.109.rev.sfr.net ([109.14.143.184] helo=smtp.tt-solutions.com) by mail.frols.com with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (envelope-from ) id 1j2ekZ-0005iU-KQ; Fri, 14 Feb 2020 18:27:35 +0100 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j2ekZ-0006QJ-7x; Fri, 14 Feb 2020 18:27:35 +0100 Date: Fri, 14 Feb 2020 18:27:35 +0100 From: Vadim Zeitlin To: "Let me illustrate..." cc: Greg Chicares MIME-Version: 1.0 Content-Type: MULTIPART/SIGNED; protocol="application/pgp-signature"; micalg=pgp-sha1; BOUNDARY="4294967295-41-1581701255=:29216" References: In-Reply-To: X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 82.232.97.23 Subject: Re: [lmi] Sharing files for two users X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 17:28:46 -0000 --4294967295-41-1581701255=:29216 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE On Fri, 14 Feb 2020 14:19:35 +0000 Greg Chicares wrote: GC> We're both sudoers, so we could just 'sudo su -' and run routinely as GC> root, but of course that's an atrocious way to implement file sharing. Unsurprisingly, I totally agree. GC> I've successfully created an "lmi" group and added both our accounts GC> to it. This looks like a perfectly reasonable thing to do to me. GC> I figured it would make sense to change our primary GID to "lmi", Is this really necessary? IMHO being a member of "lmi" group is enough. Then you just need to set the setgid (0o2000) bit (i.e. "chmod g+s") in the permissions of the directories you want to share before creating them or set it recursively and change the group recursively too if they had already been created. GC> I experimented with running GC> newgrp - lmi GC> which does let us change GID. I don't much like that, though, because GC> it starts something that's like a subshell in that 'exit' returns to GC> a "parent" shell, yet unlike a subshell in that $SHLVL is 1. As an aside, this is due to using "-" which resets the environment. Without it, $SHLVL would be 2 (or, to be pedantic, 1 more than the current one, which could be strictly greater than one if you're doing it from a subshell in a chroot inside a container inside a virtual machine inside a virtual reality simulator). GC> OTOH, we're doing all our real work in a debian chroot, where we do GC> have the power to run 'useradd' etc., so maybe I should just ignore GC> the redhat base system's limitations and set the permissions we GC> really want on the chroot. This should work too, but I think it could be less confusing to have the same users/groups inside and outside chroot. GC> As a next step, I was thinking of replacing the above commit with: GC> GC> +# Make directories and files created by this script available to other users. GC> +umask 022 GC> mkdir -p /srv/chroot/"${CHRTNAME}" GC> debootstrap "${CODENAME}" /srv/chroot/"${CHRTNAME}" http://deb.debian.org/debian/ GC> GC> which seems like a good idea: GC> - we're using 'schroot', in whose '.conf' file we can restrict GC> the chroot to our two user accounts only GC> - any file in this chroot should always be shared by both of us GC> GC> Probably 'umask 027' would be even better. The last octal digit GC> seems irrelevant if all users share the same primary GID, so I'd GC> prefer to make the "lmi" group our GID at least within the chroot. This seems a bit too broad and potentially dangerous to me, some directories are supposed to be owned by specific groups and while I can't come up with any specific examples that would be relevant inside a chroot, where you shouldn't have (m)any running daemons, I'd still apply "lmi" group ownership on a more restrictive basis, just to be sure not to break anything. GC> One way to do that is apparently to execute GC> chmod 2750 GC> on the chroot's root directory (some regard any use of the setgid GC> bit as a security concern, but here my goal is to set the chroot's GC> GID to a group with the lowest privileges and the fewest members). GC> Another way, since /srv/chroot is a separate HDD, is to use the GC> 'grpid' mount flag. Does one of those approaches seem preferable GC> to the other? I admit I hadn't even known about grpid mount option before, so I can't really say anything about it. But it's global, while chmod is more selective, so I'd use the latter on just the directories that need it. I could well be overcautious, of course, and perhaps using the mount option would work just as well and be simpler. OTOH I still don't see any advantage to using it compared to chmod on the chroot root directory: in the latter case, you can at least see the setgid bit being set in the filesystem, while in the former case the directories just magically have different permissions/group ownership, which could well be confusing to people not knowing about this mount option (who, as conclusively proven by me above, do exist). Good luck, VZ --4294967295-41-1581701255=:29216 Content-Type: APPLICATION/PGP-SIGNATURE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iEYEABECAAYFAl5G2IcACgkQBupB3k9sHoY97gCcDGmgzEYDsjI3rOwMRX57lYJ3 EuMAn0Gtr1wj9XIS5n5mAANa5e07W3TJ =RKrB -----END PGP SIGNATURE----- --4294967295-41-1581701255=:29216-- From MAILER-DAEMON Sun Feb 16 16:50:53 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j3RoT-00022v-8r for mharc-lmi@gnu.org; Sun, 16 Feb 2020 16:50:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48562) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j3RoO-00020X-58 for lmi@nongnu.org; Sun, 16 Feb 2020 16:50:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j3RoM-0004xO-LS for lmi@nongnu.org; Sun, 16 Feb 2020 16:50:48 -0500 Received: from sonic317-30.consmr.mail.bf2.yahoo.com ([74.6.129.85]:40626) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j3RoM-0004t2-Ao for lmi@nongnu.org; Sun, 16 Feb 2020 16:50:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1581889841; bh=l2EOOxP3NphgmWOWORFt5kunKxof//zTw+2keV/ZJkk=; h=To:From:Subject:Date:References:From:Subject; b=qMKpnFi9TYE1I4tWbyMVBE5KY4h4E1csAqNBR0nBvpiEXLTgE5C8M8Kr3fJF9tFFDvd0ZqdiIHNSOetxRZTqQaE9cBKP2njQEjKPbHKcru4wTnCLXZcnyZ85l52f7mXnOwewnU2AN7T+mVPhfRvV4zoqaekLf0C252aXe/+7qUYubKc/uvrpUZjQ/OSwudFgKjuk+REqnUzBwKBwPerKYmxC/KyqYf9aWWyQ4HwUaJ4sXS6qNhlZiEU5PAkExbO7VCTWL9RZUSfbewQ+pcHHEmuBUejlH3DmB7ty+d6KdXULRefPkBJ4PzAGwaPBdHzto1QzY5bGX9i1mrNlhpVsmg== X-YMail-OSG: a_.Gm7YVM1kvJKRxSUqwOF4akkF1BDw3PvHsgqBGVbDwv5L6WVsoBLcdFte7m8R Jx4.tCfDdI2VYU1quy1aKR3.lEqqSKdxat0AqMKr2j2Zq7XFon.hpLsWLz8p2uDCe.Jjm9YQY_SB iPeUOwpAT2KqR16C0mkvEklipCV4wY6oaSpsIuVu6dH1mPrDoSvyvlVORtbb6_SBNZUjhwfFPDiU NDOK__9_QYHc1U4ffX4CNU8EUJeMOnKGDEe9syeWX0TMrBFytp2lcB8CwggtEdjO6AUHeQ0QqfY9 mpsQ2C5jJRkWafzcmb_JJnguKEXu9zueHpVQ6FlpAcAx6r7hQUjUX._oEjVij3YX.LgJ.GweH3rE LRmrM0WGq23n_Gm5cxpcGV8I7pM8jjypHUtf7RQwHA8NvXqOi6Iz3dTfaIlQFl..sve116mlBSLD Z0lm3hZW.eiZUuwxGkrLfpA.JRN8igY5Jget2XxhJ9aeIvcqiOgOZ0ZeUiETBSL6SQmtwUodNmaj EXnJkM3YTSZyW70QqbMaMhNei8ae3OZbb4MytNhbOUbC6kfsqjF0rfBVudwysGuQtuWL_.ozal9d wRdF81PLZJ3zUYgqP95_ZKrO86yoZZXmhEj8jFUNxOTbvFTuPdz7EQzTwZ9dD9WFqCTMMiL2XSCC LpVpKotq43Yr3pU.XDVz_3VAarUv5VvE8bfoJmpiAl4kdAKfRAlgDxMiesaiBc4ILsYCTmyMz6TZ hXjUEZutwB8eT0xlP7rQvmLEyqeQhtBnBXBD1HK.Dyu4jZtSW.tEYoHVk0Z9DUOpyaAiSgyUPoCd n6kf0wRF7sf9CiKIeAiUuiKVu.KBNJn8wA98W0evMp4w6a0.p.LCbR9f6ZlrynIp2Rt3YG4eo.7C 2IxvIW2wzaVccrYOiM8Z_jqk4xFYcvUwgktU.p3gWJEHMacbmUbRqPjUGrHsYfjoT7QeFiB_q3lr Yv95gpXWz.YfaEdkLebrNs41wFRqRTwZGn8.kUCMaWmiR2mdlUmKmU8GBP0XHidB8eh74Ot0PymP yETsHxGOOYWV3ZuPELZ4Uf0KzT9NfiabPr0AwB8gmu.EJ5EN6iB4Dw.iJucFsvE1fMgz8Y_hGaOV ErX_blf93ucsVG5GhifGpd3mbDb_.8YLOKdO5EyzwBsRX2gDbeeRwefd_6ix5sezbRqd51ZspQel G8Q2RwM2e9qBdlMTuSzNUzHgmVckjY8RAzWSy8h.SQxfQBhCxfdx7glAVphxfaYwB4i7vtQ_Y.KU yLej624xPP9b90kOiXxnQ1EzagFlQOEK_ibQtH27rF68AF6ZgwRH2iTewEj6_hr.L_LGKObp6p4E 4unw0T3cI8oZeNGJ5VXDKfoGttirgD7f5VreSSIM9WfWWUQH8CzmzHrCj4VFyLO9Si_N2KztDY8M IIFjplcg3dlgK5i_WlhL8 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Sun, 16 Feb 2020 21:50:41 +0000 Received: by smtp410.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 49856679f1d437d30bd93601984bd57e; Sun, 16 Feb 2020 21:50:39 +0000 (UTC) To: "Let me illustrate..." From: Greg Chicares Message-ID: <76ba95d0-a5c7-3e0d-cf32-869e39c78a4d@sbcglobal.net> Date: Sun, 16 Feb 2020 21:50:37 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit References: <76ba95d0-a5c7-3e0d-cf32-869e39c78a4d.ref@sbcglobal.net> X-Mailer: WebService/1.1.15199 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_181) Content-Length: 1993 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.129.85 Subject: [lmi] Is 'chmod 771' merely silly, yet not harmful? X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2020 21:50:50 -0000 Invoking 'install_redhat.sh' causes these commands to be executed: mkdir -p /srv/chroot/"${CHRTNAME}" chgrp lmi /srv/chroot/"${CHRTNAME}" chmod 2770 /srv/chroot/"${CHRTNAME}" umask 0007 ... schroot --chroot=${CHRTNAME} --user=root --directory=/tmp ./lmi_setup_20.sh and then, in 'lmi_setup_20.sh' (in the chroot, as the root user): # https://wiki.debian.org/chroot#Configuration cat >/usr/sbin/policy-rc.d <) id 1j3TU0-00059T-FX for lmi@nongnu.org; Sun, 16 Feb 2020 18:37:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j3TTy-0000V4-RS for lmi@nongnu.org; Sun, 16 Feb 2020 18:37:52 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:55660 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j3TTy-0000PS-Jp for lmi@nongnu.org; Sun, 16 Feb 2020 18:37:50 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j3TTu-0007gI-Oc; Mon, 17 Feb 2020 00:37:46 +0100 Date: Mon, 17 Feb 2020 00:37:46 +0100 From: Vadim Zeitlin To: "Let me illustrate..." cc: Greg Chicares MIME-Version: 1.0 Content-Type: MULTIPART/SIGNED; protocol="application/pgp-signature"; micalg=pgp-sha1; BOUNDARY="4294967295-41-1581896266=:29216" References: <76ba95d0-a5c7-3e0d-cf32-869e39c78a4d.ref@sbcglobal.net> <76ba95d0-a5c7-3e0d-cf32-869e39c78a4d@sbcglobal.net> In-Reply-To: <76ba95d0-a5c7-3e0d-cf32-869e39c78a4d@sbcglobal.net> X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.240.17.225 Subject: Re: [lmi] Is 'chmod 771' merely silly, yet not harmful? X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2020 23:37:53 -0000 --4294967295-41-1581896266=:29216 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE On Sun, 16 Feb 2020 21:50:37 +0000 Greg Chicares wrote: GC> Invoking 'install_redhat.sh' causes these commands to be executed: GC> GC> mkdir -p /srv/chroot/"${CHRTNAME}" GC> chgrp lmi /srv/chroot/"${CHRTNAME}" GC> chmod 2770 /srv/chroot/"${CHRTNAME}" GC> umask 0007 I'm curious, what's the reason for using such restrictive umask for the "other" users, especially knowing that they aren't supposed to be any? GC> which gives /var/chroot.../usr/sbin/policy-rc.d 0771 permissions GC> and ownership of root:lmi. [...] GC> Vadim--Do you agree that this doesn't require any correction? I'm not really sure about this. In principle, it doesn't seem implausible that some script might want to execute this script as some system user, using some system group (e.g. Debian-exim:mail to give a random example) and would fail to do its permissions because, even though it has "x" bit set for all users, it doesn't allow non-root non-lmi users to read it and shell scripts need to be readable in order to be executable. Of course, such scenario might never occur, but if it does, and some software package doesn't realize that it's being executed inside a chroot, it might result in some difficult to diagnose and debug problems. So I would feel better if the file had 0775 permissions. GC> Nobody except root and members of group "lmi" should ever use GC> this chroot anyway, so in the "u g o" model, "o" for other GC> users is the empty set. Not quite, there are also system pseudo-users. GC> It doesn't matter that group "lmi" members can write this file, because GC> they wouldn't want to. This is also somewhat questionable: we don't run our systems as root partially because this would allow us to accidentally change many files we don't really want to write to. But in practice this seems unlikely to happen, of course. GC> I suppose I could GC> chmod [...]/policy-rc.d --reference=[...]/tzconfig GC> but that breaks if we ever use BSD or if 'tzconfig' fails GC> to exist in this exact directory. What I don't understand is why can't you just do "chmod 755" on it? Is there something obvious I'm missing here? Because this looks like by far the simplest way to ensure that no problems happen. Regards, VZ --4294967295-41-1581896266=:29216 Content-Type: APPLICATION/PGP-SIGNATURE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iEYEABECAAYFAl5J0koACgkQBupB3k9sHoacjACfTNS3ACK6Hd1iO2f+Hr8gqvTW I0wAnjht6vi1pSjudH50O3IbOssBgy/n =rf0x -----END PGP SIGNATURE----- --4294967295-41-1581896266=:29216-- From MAILER-DAEMON Mon Feb 17 18:12:45 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j3pZF-0005lm-3d for mharc-lmi@gnu.org; Mon, 17 Feb 2020 18:12:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57662) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j3pZC-0005lQ-FN for lmi@nongnu.org; Mon, 17 Feb 2020 18:12:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j3pZB-0000E7-Cg for lmi@nongnu.org; Mon, 17 Feb 2020 18:12:42 -0500 Received: from sonic311-20.consmr.mail.bf2.yahoo.com ([74.6.131.194]:45504) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j3pZB-000084-42 for lmi@nongnu.org; Mon, 17 Feb 2020 18:12:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1581981157; bh=sOxiEuLYLyQPouh7TzEifo5JD1mGkf5kKSHVCSUaUU0=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=rCc36+znZHO+MdSOsWlAIhdEq+8xqSoUChhHfbm3YKspCnmHYr9KXA1mLDYGyHz1mNV+Ha3fCHeZdulgWR7XhG3dzfomOkdAFiKSuYyJ97QFUb172xDpRB/c/6RSiEWHWP49NV7B1nKWoDeGyCViurkpDMM7L23HTAAuCsYXThyNX8rnIj8KWJolSsmWfvJAv4nGjP4BoaJ+Tc5Pa4kp9QJYZIVP2/MWUtPMs9vCWentcbiFU8pxGU9xs7dOMRmm7OqqR8TXdKfT8zaDwT2UuUG6Iyr6+Q3XT1BgsUoSbefiC9c5q1DuguyDJNGyV3p6yKhfORwRTv8Ht0nNmJIpWw== X-YMail-OSG: bfx6me0VM1kkPqWJSBzEbVbbN8PXb4CuqSpTThEC5GSQojEdeDh.Y578Vt9prIY WgsDiVAzCUuJ6lgSyN_mRm7k6JN9ErSmfvJnWnSeP5jO6WAFOFIfXEuJp.V9Xgg6GecqgbrwrFOd 0ADVSx4Jez8FyHz_OwUzOPs_h.DSRK9UeSifXCdJPIeiBfD2NTL4tpjTAPS2dtJdzD5_BJtkKyTS 3dBvB3jpUqRO4JMVstsV2CInkkNdGMlPNIoaIzrVaG6EpOd9uQJ9hFU3G1FSIBkV.zE7MPyt9hDY BAUIKHJro5wQRcEqSK7SESsdzndq0fx9GXD25GDoYIe10rILNwuOmP4whI6N8KZv2SUrxK3QowQR HYHxzEFtzKYcyTxE0MsGgs49IMT8alNhqkkc7FeDJn2WbPh_p1bYjMunvG2XF_4lJGrtAoNGEbi8 zN4T8eCdTKxklXIlJPdyE.joSw4fJ7X9nBWX8GkKUfbEOV6XiNTwl.9RYCp_ZNW6cx0Zg7QsLDez EPjrf5aQD6eaYBjwhL.LUpP4gjGysJx.v7xIy.IH2GqTNuIpCsBtk416vT3lhFxSRkXGiZ.BJ4cL ExzChxa0Kc_wpbB4oJPMQgwxuzxkNmj.m5q_VMvWYtwNxGm_71KyONpKDhm1akngRO6j8lL0__XF CpUy8JustQBFG4ZSdlggFwiapwnYjwMHGUvOPNe8ZwGV.dGiVudZdQAAVaIHInbjA_jXS1qGmupQ VFHNibI3Kpm_5TZWCosdGxatEOyl_CEexqHFKwT49hGPDGf9XckCr_3iKabteTAgFTtUbkxIGrPH u9019PvDVJRE.FJ0keCCZKUaHRyjoVAcBvAvEO_32LjfpGDISB6N5hfGSzl3R2y3Dp7pDhxwP.j0 D1AQ9w9RS468vjpjvulTRWzWM2XBsYoYAt4qv53tcbC0t9Mxols6U3VZLnKtVoIL.HZOtA9ZxzHa YDOZTOSugRYc.hndr7j2rOE5xfw.uUbDjtQCBsKpeFwmr3Qrs0XmQSDFNWoiFTjCVt1j9GaygBDQ dMF_OK0RQaQMaGUE0vSCS_3Um8gdXSySVszKo9Dpsyi8yTj6y2zud15Q8K5YiM1KIttfw_m8mpFI Q.SDSOmERyTr4EPwgwSl2vYlo_RAsvtB4c34CcAGZwFaszmfHCBRA7C7rgFhv6nOmEL3yEux.8S3 B_7zZX3dgLO3kC5cjhoNU7z0uXoMoWC7ZpYi4fX9e9dyFphbc5695dYyyBF8EYhKOCyITwPfzD5q xSDKjr2pvzIpBWlVEdRfQZ7OBUkOeSBndtkP0_EEbFOM0y_uFc0PjCGb.sKhzTBs0sINHHFKDugU cfiR.XxKUU3sWvARTX6H60XVNS7fQxcrp28FJW0aIyEpXKlMATU5Ec9x.tJ0y5LvWZDf7jP6JEjJ 7G3yaY5GlRryQtM0OjYLZYmht Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Mon, 17 Feb 2020 23:12:37 +0000 Received: by smtp426.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e31cda90e17e66546873c8ff501d4034; Mon, 17 Feb 2020 23:12:36 +0000 (UTC) To: "Let me illustrate..." References: <76ba95d0-a5c7-3e0d-cf32-869e39c78a4d.ref@sbcglobal.net> <76ba95d0-a5c7-3e0d-cf32-869e39c78a4d@sbcglobal.net> From: Greg Chicares Message-ID: Date: Mon, 17 Feb 2020 23:12:34 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.15199 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_181) Content-Length: 1581 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.131.194 Subject: Re: [lmi] Is 'chmod 771' merely silly, yet not harmful? X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 23:12:43 -0000 On 2020-02-16 23:37, Vadim Zeitlin wrote: > On Sun, 16 Feb 2020 21:50:37 +0000 Greg Chicares wrote: > > GC> Invoking 'install_redhat.sh' causes these commands to be executed: > GC> > GC> mkdir -p /srv/chroot/"${CHRTNAME}" > GC> chgrp lmi /srv/chroot/"${CHRTNAME}" > GC> chmod 2770 /srv/chroot/"${CHRTNAME}" > GC> umask 0007 > > I'm curious, what's the reason for using such restrictive umask for the > "other" users, especially knowing that they aren't supposed to be any? If I spent an hour reading about coronavirus, and I had a face mask handy, I might start wearing it. (If I had read just enough, that is, to be ill informed; with more thorough knowledge, I'd realize that the main benefit of a face mask is to make an already-infected wearer less likely to infect others.) In this case, I read some articles claiming that a default 022 umask is too liberal, and 027 is more secure. Accordingly, I chose 007 here instead of 002. But tell me if you'd prefer 002 and I'll make it so. > GC> which gives /var/chroot.../usr/sbin/policy-rc.d 0771 permissions > GC> and ownership of root:lmi. > [...] > GC> Vadim--Do you agree that this doesn't require any correction? [...] > What I don't understand is why can't you just do "chmod 755" on it? Is > there something obvious I'm missing here? Because this looks like by far > the simplest way to ensure that no problems happen. I was trying to decide among the various complex approaches that had occurred to me, and this simple idea didn't cross my mind. Adopted in commit 2bfa77a4366. From MAILER-DAEMON Mon Feb 17 18:27:40 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j3png-0008Oa-Hj for mharc-lmi@gnu.org; Mon, 17 Feb 2020 18:27:40 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59614) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j3pnd-0008K5-3y for lmi@nongnu.org; Mon, 17 Feb 2020 18:27:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j3pnb-0000Th-CN for lmi@nongnu.org; Mon, 17 Feb 2020 18:27:36 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:41526 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j3pna-0000Re-54 for lmi@nongnu.org; Mon, 17 Feb 2020 18:27:34 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j3pnW-0005V4-Q9; Tue, 18 Feb 2020 00:27:30 +0100 Date: Tue, 18 Feb 2020 00:27:30 +0100 From: Vadim Zeitlin To: "Let me illustrate..." cc: Greg Chicares MIME-Version: 1.0 Content-Type: MULTIPART/SIGNED; protocol="application/pgp-signature"; micalg=pgp-sha1; BOUNDARY="4294967295-41-1581982050=:29216" References: <76ba95d0-a5c7-3e0d-cf32-869e39c78a4d.ref@sbcglobal.net><76ba95d0-a5c7-3e0d-cf32-869e39c78a4d@sbcglobal.net> In-Reply-To: X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.240.17.225 Subject: Re: [lmi] Is 'chmod 771' merely silly, yet not harmful? X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 23:27:38 -0000 --4294967295-41-1581982050=:29216 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE On Mon, 17 Feb 2020 23:12:34 +0000 Greg Chicares wrote: GC> On 2020-02-16 23:37, Vadim Zeitlin wrote: GC> > On Sun, 16 Feb 2020 21:50:37 +0000 Greg Chicares wrote: GC> > GC> > GC> Invoking 'install_redhat.sh' causes these commands to be executed: GC> > GC> GC> > GC> mkdir -p /srv/chroot/"${CHRTNAME}" GC> > GC> chgrp lmi /srv/chroot/"${CHRTNAME}" GC> > GC> chmod 2770 /srv/chroot/"${CHRTNAME}" GC> > GC> umask 0007 GC> > GC> > I'm curious, what's the reason for using such restrictive umask for the GC> > "other" users, especially knowing that they aren't supposed to be any? GC> GC> If I spent an hour reading about coronavirus, and I had a face mask GC> handy, I might start wearing it. (If I had read just enough, that is, GC> to be ill informed; with more thorough knowledge, I'd realize that GC> the main benefit of a face mask is to make an already-infected wearer GC> less likely to infect others.) GC> GC> In this case, I read some articles claiming that a default 022 umask GC> is too liberal, and 027 is more secure. Accordingly, I chose 007 here GC> instead of 002. But tell me if you'd prefer 002 and I'll make it so. I don't really have any preferences here, considering that you're telling me that there are not going to be any other users on this system anyhow. FWIW I also don't believe in relying on umask for security on really multiuser systems, IMO setting 0700 mode on your home directory is both enough and better anyhow. But OTOH I can't imagine any problems due to using this umask on this system neither. Sorry for this non-answer but I really struggle to think of any reason to either endorse or object to using this umask. VZ --4294967295-41-1581982050=:29216 Content-Type: APPLICATION/PGP-SIGNATURE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iEYEABECAAYFAl5LIWIACgkQBupB3k9sHoahywCgknzmNKcq5RnKgwVYjz3Sj73H QZIAn0WusA9eJpcV9otS7myMzIir1gpG =I3V6 -----END PGP SIGNATURE----- --4294967295-41-1581982050=:29216-- From MAILER-DAEMON Wed Feb 19 15:43:44 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j4WC7-0004Jk-V9 for mharc-lmi@gnu.org; Wed, 19 Feb 2020 15:43:43 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50932) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4WC5-0004JP-5n for lmi@nongnu.org; Wed, 19 Feb 2020 15:43:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j4WC3-0005TG-T0 for lmi@nongnu.org; Wed, 19 Feb 2020 15:43:41 -0500 Received: from sonic311-19.consmr.mail.bf2.yahoo.com ([74.6.131.193]:41085) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j4WC3-0005S0-K8 for lmi@nongnu.org; Wed, 19 Feb 2020 15:43:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1582145016; bh=qDxCANhy0iFp1wlRJUS97XMUNj9Nl7dqzlWMVT+eT7g=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=jcdj5KAD9ANrE+UZLzzqpmHetCSCQOmDX8z0pfLAycH39+kMMASBNUALttk1N/1G2L2SyAo164A5Eh+jNmGX2ndIwVOUp4W8t58tmIX+xLSYxLd56gkE1nOFznEF8mIvH3VKmlqI2yr+PebXaJiOC9ipvSpeZRuKd7G7IL+nuhw7xWQ38F0z9EWJrD1jinBIs9EsGctvKS1FHMGk5GbRklStaVHRFDfgCi1K3RWjXt8bOhCXXz8noTS3G4lpgcl7BSRWVuyiT1EBZFiNyycjh9wXJihs7ajYYTquQNmeVS3oimSb6fw49EcvBe3sjoVu7XiAj3BM4Iab+AIAmsBt+g== X-YMail-OSG: oS7agZsVM1kn44RcyPiT39YH8ekYcbNhj1PhSvCsqgiwU_mJJV7KKaMebA2MtOb lzEd65pfg_4w0EvjbRhe8.xOyAjXnSH1KPbN1aofJ0mbLk.yauw0kQyGXGT1GEScE249imDf_bLI wojkEslfKjGHpexQI0XNUwglU5IH070VFkk_AICkdlMEab1AP00HMFwxGN3qBxWAar23Jte2K4cN 5HBXLyRtVmeggLe3EV.Aw49SE_jkRPgjSkOCjlW3NBpDeml9J2qTeAWWnR2ebL2GOLIcSQ_fJr0C VlI0xaLXzqr92_YvvDL1.qHvnghRuiVSwsuvFYR0AwE28IldHWaSx7K_9_.Fa4KKI5NxqTeQZi3c hHxbJvRT5bF9xbrJAEi_qv.KiDMO9CEm0wRSAj59oKo1XEtzE8vfDbQJOJtZKMMMTKf08l9GR3FM LIfpezqw5DEQ7nddiLa.pomMS3jelV7Qbgn3ZgxgWUfNcpFTjvscvQ9sY_vxb7eIk3ibd.d7JJnd yMduefPesbRYsBJeIIDnyLsJxykksqS91QUzCcjUi13KrN9IZTTKbSNnlWL7CBAdzCAyRf6SCH8C Pij9CAEeMDvML8qzCP.bQ97giOuArerfvf6Eto.SLucZ20x5.9VNHfYTLOjQ.v64f6LGnLC53VX. IeNu9dgXeGpJtas_PxwwTXbX65j9l1qO1BXhiTvQ91x3cQ1RJfdZbFmYJxyizmguvgFj5NatudyZ WHmSUSxQyfD3hARPJDOxDLnxCUlPIVZmJ9ZBXjdbHRPGxhiUVRT78AQfmPaHbCbpWEJgAODoSYNB sjuJ.dspKNbSZg3CgYKjoDpAHH0ltnL.HVOjHshgdqfoh68oUfwBw2tD2rnd3Ar6XwsVgQ7Rn7cS iWyE_eECYddmhqxRKeo4aMz8_k38cLF.XQjPS4bV_cQNUGXlC4eDa0vNA.1gOs512WxEUjOWZoLF 6U6Ivg8X0P.JsV3VP9GgDvia2hoGuFXuhDS46fhL.588phY4UjrzRNEJvm9TIYh24t4EBWp_BC63 RIbRYbAHH09XARC8tCmNgvOynzPCJVIn7jZi2iYW6hwuOxLxLqJxoVh1vfr5JIeqqRc61N2wI.72 mpBcwZIyysksk_iVPhSzujkmRBvyUSuoG.WwiJuqKM16FMzMhwqHo5gNIkRGeXGscktFw9pUfsMa yy._CDucdLZwxLD3ZLgqgdTXVanm.ZtuHWKx_oK7JSpYJPXZvPWuWY7XBmhDGTqDDf61OgJbi6E8 hbK9HJwVhX_gDpWu3MNwKjP7hkEdk3.EevRIV3MYt1wBzoBla8RHXr9tuiBl1riQONPO5wIMymBl i8T6PVCBRoos.s0xdzG10seBJG3PIopy8uBIk0t3po7iscRkdQspyEtm6JtAq_nmwOUxXHJBSQ34 _ws.XJ.UxA74CXYmGMVkZ Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Wed, 19 Feb 2020 20:43:36 +0000 Received: by smtp422.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID aba6533955fc64d46e035ff1d84aa9ea; Wed, 19 Feb 2020 20:43:35 +0000 (UTC) To: "Let me illustrate..." References: <76ba95d0-a5c7-3e0d-cf32-869e39c78a4d.ref@sbcglobal.net> <76ba95d0-a5c7-3e0d-cf32-869e39c78a4d@sbcglobal.net> From: Greg Chicares Message-ID: <412441a3-056a-195c-5b4c-08cf51ca8f1f@sbcglobal.net> Date: Wed, 19 Feb 2020 20:43:33 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.15199 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_181) Content-Length: 2815 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.131.193 Subject: Re: [lmi] Is 'chmod 771' merely silly, yet not harmful? X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 20:43:42 -0000 On 2020-02-17 23:27, Vadim Zeitlin wrote: > On Mon, 17 Feb 2020 23:12:34 +0000 Greg Chicares wrote: > > GC> On 2020-02-16 23:37, Vadim Zeitlin wrote: > GC> > On Sun, 16 Feb 2020 21:50:37 +0000 Greg Chicares wrote: > GC> > > GC> > GC> Invoking 'install_redhat.sh' causes these commands to be executed: > GC> > GC> > GC> > GC> mkdir -p /srv/chroot/"${CHRTNAME}" > GC> > GC> chgrp lmi /srv/chroot/"${CHRTNAME}" > GC> > GC> chmod 2770 /srv/chroot/"${CHRTNAME}" > GC> > GC> umask 0007 > GC> > > GC> > I'm curious, what's the reason for using such restrictive umask for the > GC> > "other" users, especially knowing that they aren't supposed to be any? [...] > GC> In this case, I read some articles claiming that a default 022 umask > GC> is too liberal, and 027 is more secure. Accordingly, I chose 007 here > GC> instead of 002. But tell me if you'd prefer 002 and I'll make it so. > > I don't really have any preferences here, considering that [...snip...] I'm going to undo all these unclean workarounds and redo it the right way. I believe I've found that the root cause was the line that set 'umask 077' in etc/corporate_profile . Fixing that seems to make everything work: in particular, it prevents the problem (see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876703#20 ) that started this wild goose chase--now, my normal unprivileged user can enter the chroot successfully, and its root-directory permissions are the same on the redhat server as on my debian machine: /srv/chroot/bullseye0[0]#ls -ld /srv/chroot/bullseye0 drwxr-xr-x 18 root root 4096 Sep 12 23:02 /srv/chroot/bullseye0 Accumulated workarounds had resulted in this mess: /srv/chroot/lmi_bullseye_1[0]#ls -ld * ... dr-xr-xr-x 282 root root 0 Jul 1 2019 proc drwx--S--- 3 root root 4096 Feb 17 15:34 root drwxr-xr-x 4 root root 4096 Feb 17 15:31 run lrwxrwxrwx 1 root lmi 8 Feb 17 15:31 sbin -> usr/sbin drwxr-sr-x 2 root root 4096 Feb 17 15:31 srv drwxr-xr-x 2 root root 4096 Jul 9 2019 sys drwxrwxrwt 5 root root 4096 Feb 17 16:10 tmp drwxr-sr-x 16 root lmi 4096 Feb 17 15:33 usr where the capitalization of 'S' in "drwx--S---" indicates insanity, and fluttering between "root:root" and "root:lmi" ownership seems capricious at best. Furthermore, suppressing the silly workarounds and setting 'umask 022' before regenerating the chroot makes this warning go away: W: Download is performed unsandboxed as root as file '/var/lib/apt/lists/partial/deb.debian.org_debian_dists_bullseye_InRelease' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied) so the more restrictive umask actually defeated a security measure. From MAILER-DAEMON Wed Feb 19 18:48:46 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j4Z5C-00019W-6B for mharc-lmi@gnu.org; Wed, 19 Feb 2020 18:48:46 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47430) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4Z5A-00019P-6D for lmi@nongnu.org; Wed, 19 Feb 2020 18:48:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j4Z59-0007uD-74 for lmi@nongnu.org; Wed, 19 Feb 2020 18:48:44 -0500 Received: from sonic312-24.consmr.mail.bf2.yahoo.com ([74.6.128.86]:45358) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j4Z58-0007tu-UD for lmi@nongnu.org; Wed, 19 Feb 2020 18:48:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1582156121; bh=2sS+Z/ZpcJoqhPZppmwaI+ejUTt0xITAYHADebDukXA=; h=To:From:Subject:Date:References:From:Subject; b=JVrE2mxos7x0GB3YGOa1BVZwmFnPSEK8VJJIouG5ISYLFNw43etjv6hNfjDHt7afO+GSwPnBENFQZYpyNJeq/4fRiSzvPSWLSkpxybo6HCxQ+xMiFwifZydZ9M3GZd1hlw7GW8ec87EbtuzT7VhgjbAHgjcuPnSuffb6LsSog+RvNjtXXg8oTnAqBRTFe/j2VUnxC4kQUFtAeJ+wZfZm/tSUdQwx3nHiv5/Q+Q0q77p9CWVkfdOsPSTgji9012FAjIAFjaKVLxb1GZCv9vNFDe2o7sKYIvXGjF5ZioX42HUYoiEWTw7xPbLXdo8KOz02wNx5xaRnfygTuNOZbXujjA== X-YMail-OSG: J56zEL0VM1lT7yek0ZGaXtbPxaxUUpoCoBSpN2drKaPfdAZEe8PUoUEEs8g9JRz NidHX77LTs2AndFSkpDaYgHe_ynkM1ZbabTS0BHMxv3EMxK6947ovYE5b2dEGeBrTF3kdDWNTySY Ruk09bDfringp3CNOvjC8JEj0tISkQDGAWa7RbQGs6I7Urq6uSjxHplv.a7LAWkntfR17hjGH5uW PXIJEk1ySe7u8viDRUm8IpFCWoOfV_S9IXIIcFQ0aI.HlwnSFqZO97y7rM9OrSMyXGEv.yhLGq3Y .DxycxIThr1j8uFCqX2Vjkp.f6xw5xX4DXThMW5.gRymu1JWNirPvzdUaTyDIsEnpKNYP5cu3d1k jITqIEpbXKCDO.b8hnT7RapoIuXpl0tsVqqFr.87Yd29ysNdzwffLxVFxl5SbpX0pB2XoeWy.IIu bCBNNHBNL.F9MxtFcCq0yc_wb4HF_LNYYbmllLdn4PmaI_JgIYI7.sW_iSSN_XD8GEbIwI0ExPv_ nTkA4i_d7ZZ.XR226_acZPHtG8sU2nKuUgTIdXXBTmjsb14q5ZtCDdL9WEgSLVYVfft9PiePCdEH Ms002Mh8NJ8a2Gdjd65XWhltXa6xwcAC92HIhpWDTpEnSox8wYn4hKntUq1jIkkJAf1TtB66rJ2u hCytnKBIlViUoPcXxnlu__Q2N4F1mbbM9sg_1e._PUbgZbyEbnpOFiK55trxyMUJs7jiMVQsLe8n q9k9xCBP1lWHslDXua7pHnMCm8kRv2i3gLn2UCSJeDdIf12iqGlDJQ6XJ8alWsmkEbEntmKPqaVM GShuCynXS8pcdge6f.PjNR4Q5CZ8mlzwuNFNFtxnX5qzSe7BYmNxOosL.HT8h0S3ELiTqhdhXnwM mxu8Z4XNKhF6iu5ZIcWV5m3qqaqDaXm1dn7_WW9CqlMDBzoXCgOjqymRRQKpb8QtRZwvCDqgIqnY 8sjrHdjZwyr.QUnICq0tzui_6qnzW_E7w_az9HIuUwq0zUXD8IT3G9zq07RzMCxqvQgnjo7w2i5P YFj3wE88c2T5xx2S07njUC5zEQYGVT90PUul_6v6aI4ZEVXem6zwmZTjbKHlRla_MutUiFd.I7OZ orIjOaOlekt3ciDUWBQBoLtvxmONuDp4canCW3TVG_9ybhMnken_sTIhffRXeEMnsyp6auJvsJGB VuUEo.j7ydncmtNYD4gp2ModC.t9A.1YXMPyzTvLMlIDaBhBV_2lcCyjny5AoCGcRaKb7xTY_MOY sPPzIV7geXvmr3SQcqd_0n7UPOuLsCDdAz1uMDOM6ZhRqwAR9RwcGDhnatfhMOlErdjxKx1GDXDn bEuTP1_T6crLmHfemBXNfBf1MOM3RTThldPbtw8chhB.rd7FOEIBudOQAAU9.JhCmhpppGlFPtdu GQaQwt_iDD4xSC3filov81KfM Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Wed, 19 Feb 2020 23:48:41 +0000 Received: by smtp412.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 645e4e4785ca8f6bb7c14fc32defb1ec; Wed, 19 Feb 2020 23:48:37 +0000 (UTC) To: "Let me illustrate..." From: Greg Chicares Message-ID: <5812360f-5fb0-3f6c-5763-52f2f2210cdc@sbcglobal.net> Date: Wed, 19 Feb 2020 23:48:36 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit References: <5812360f-5fb0-3f6c-5763-52f2f2210cdc.ref@sbcglobal.net> X-Mailer: WebService/1.1.15199 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_181) Content-Length: 843 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.128.86 Subject: [lmi] zOMG SELinux X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 23:48:45 -0000 Yesterday, no dots in 'ls -l' output: /srv/chroot/lmi_bullseye_1[0]#ls -ld * lrwxrwxrwx 1 root lmi 7 Feb 17 15:31 bin -> usr/bin drwxr-xr-x 2 root root 4096 Jul 9 2019 boot ^ no dots Today, after an upgrade from RHEL-7.6 to 7.7: /srv/chroot/lmi_bullseye_1[0]#ls -ld * lrwxrwxrwx. 1 root root 7 Feb 19 15:53 bin -> usr/bin drwxr-xr-x. 2 root root 4096 Jul 9 2019 boot ^ dots so they've turned on SELinux. Well, kind of: $ getenforce Permissive But I've rerun this command since that change: $sudo ./install_redhat.sh and the logs look just fine, so everything seems to be working. And sudo grep "selinux" /var/log/messages shows no complaints about anything I've done so far. Should I anticipate problems? Is there anything I need to learn now? From MAILER-DAEMON Wed Feb 19 19:20:56 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j4ZaK-0000pq-12 for mharc-lmi@gnu.org; Wed, 19 Feb 2020 19:20:56 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51180) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4ZaH-0000pf-ID for lmi@nongnu.org; Wed, 19 Feb 2020 19:20:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j4ZaF-0005pH-TB for lmi@nongnu.org; Wed, 19 Feb 2020 19:20:52 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:42236 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j4ZaF-0005nr-G6 for lmi@nongnu.org; Wed, 19 Feb 2020 19:20:51 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j4ZaB-00016G-VL; Thu, 20 Feb 2020 01:20:48 +0100 Date: Thu, 20 Feb 2020 01:20:43 +0100 From: Vadim Zeitlin To: "Let me illustrate..." cc: Greg Chicares MIME-Version: 1.0 Content-Type: MULTIPART/SIGNED; protocol="application/pgp-signature"; micalg=pgp-sha1; BOUNDARY="33171773-856-1582158048=:36804" References: <5812360f-5fb0-3f6c-5763-52f2f2210cdc.ref@sbcglobal.net> <5812360f-5fb0-3f6c-5763-52f2f2210cdc@sbcglobal.net> In-Reply-To: <5812360f-5fb0-3f6c-5763-52f2f2210cdc@sbcglobal.net> X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.240.17.225 Subject: Re: [lmi] zOMG SELinux X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 00:20:54 -0000 --33171773-856-1582158048=:36804 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE On Wed, 19 Feb 2020 23:48:36 +0000 Greg Chicares wrote: GC> Yesterday, no dots in 'ls -l' output: GC> GC> /srv/chroot/lmi_bullseye_1[0]#ls -ld * GC> lrwxrwxrwx 1 root lmi 7 Feb 17 15:31 bin -> usr/bin GC> drwxr-xr-x 2 root root 4096 Jul 9 2019 boot GC> ^ no dots GC> GC> Today, after an upgrade from RHEL-7.6 to 7.7: GC> GC> /srv/chroot/lmi_bullseye_1[0]#ls -ld * GC> lrwxrwxrwx. 1 root root 7 Feb 19 15:53 bin -> usr/bin GC> drwxr-xr-x. 2 root root 4096 Jul 9 2019 boot GC> ^ dots GC> GC> so they've turned on SELinux. I'm rather surprised this has happened during a minor version OS upgrade. I quickly tried to find any mention of this but couldn't. The release notes https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/7.7_release_notes/index have many mentions of SELinux, but nothing about enabling it automatically. So it looks like this was done intentionally by the system administrators, which might indicate that they plan to switch it into enforcing note later. GC> Well, kind of: GC> GC> $ getenforce GC> Permissive GC> GC> But I've rerun this command since that change: GC> $sudo ./install_redhat.sh GC> and the logs look just fine, so everything seems to be working. GC> And GC> sudo grep "selinux" /var/log/messages GC> shows no complaints about anything I've done so far. I don't think lmi should be affected by SELinux, which mostly/usually only applies to the services/daemons. GC> Should I anticipate problems? Is there anything I need to learn now? Unfortunately I don't know much about SELinux, so it's perfectly possible that I'm not aware of some of its effects, but with the current state of my knowledge/ignorance I'm tempted to answer "no" to both questions. Regards, VZ --33171773-856-1582158048=:36804 Content-Type: APPLICATION/PGP-SIGNATURE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iEYEABECAAYFAl5N0NsACgkQBupB3k9sHoZV2QCfS5upU3q9CzaHHTBi5B7BiK2P ldAAnitFWyGWkAZ8LpG6Nsm74vYNB81a =Q6Zr -----END PGP SIGNATURE----- --33171773-856-1582158048=:36804-- From MAILER-DAEMON Thu Feb 20 17:58:47 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j4umN-0002cx-89 for mharc-lmi@gnu.org; Thu, 20 Feb 2020 17:58:47 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55778) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4umK-0002cq-7z for lmi@nongnu.org; Thu, 20 Feb 2020 17:58:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j4umI-0000Qz-Rr for lmi@nongnu.org; Thu, 20 Feb 2020 17:58:44 -0500 Received: from sonic315-19.consmr.mail.bf2.yahoo.com ([74.6.134.193]:36717) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j4umI-0000Pl-Iz for lmi@nongnu.org; Thu, 20 Feb 2020 17:58:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1582239519; bh=CCQAnHZHEzHTTd1od2HxKEb3MPzg3AN+rNVDCKHT60Q=; h=To:From:Subject:Date:References:From:Subject; b=dzBFLy8offIE/VvIcJ+Yx5/dTgj/TnAEoC1ilVMToP/JeQXLi2QBQqZad/7mVYxPkdOl24b2i+dDYvRqk1IxZdbaPTVNsyBH3UsWv+pCARaUkuQY5nypTMjTOaxNxSZIsYNzx/kq0pYGZTSDWqhTkPqM+zaP2P0yuy12kqcg3/cIEEli6euhL42lFAA/rdPxHjP+IfGd/RD7leRDDPZlM7hGa/AcBYuemmd49MK3nOWV4WAEi60grJm0aM6tRqVIpt43yyQOMThh2puLGUMTmauk+QZd7g4YlSFVcehvzyLgCwylbSaD24fTqOZERX60whs1i97Ak3Pets0ql6YpLw== X-YMail-OSG: PLa6vVkVM1l_M0NPzLqPWbSGMx9Lqrtz1xMkSesrfcc7ITSAu7Hk4cC90B45.vm qlaPlPD7uPZvPbJyVyF51ku3EfAG3K_wFLjcwMtzzYRxsa_3jjgJTV.WvwTJ.Aw2xn_trD021Adm _QSVkzp.wbK2oHGng_KZtTTIVSIqcntT7ZRawJtCu_mzsbE8e5m3A7atMn7Jyja4q5echXoVkX8Q 0ker7aa7f1oV7pZf5pUCjspxuIzxHRKYxhZlEFXEG.1ml0v..r0DWQAIFtLVeqZtDCW0sMjJtzgs q.29Dd93FdWvaf69uGlMhuO_S.kcX7VGWb87DC.0w.tQjaY.jmDelFsh3dlMO78SguN.sHFvTcgz _vCCblDLfDrRreEFTj5FQv9Eo1XeT0m8MhNvnVQxfPFo47U5hJPcwbWD0En0euSdPbs_71FNbdv3 6I.Elnk.vLXAReILRDFBVN1Y_FKp0wW7KX81II7DXUEBYWAV692ZsfKtKD8i_T_FGSXBYG0uGYng cqpSryxei47pxEcAcxSv4PbWVR3UZKaJ2.UKReVujsnLdR_xZF94vIInnj6faQ1DIsfTG3OdWsgx Yo.5rFPG7J9oEvKAHJviJvliT8DPXKZ9EKgsEs0BhPP4kMD8W2Y7GYq.LnsoxIHQwzja28h2X83E ukv4mCJuOPW2U97QnaSU3gzZcSEmLRk2tDW0k40v81L2iGMvTv8FhECCPK7BrlN7dlozhp04k7vo ChK8k_EH53tR8pgOpoi5uXsYp1Yi6b4bLfNESssc7JGCO9m2mSvIYzCYrKJHSZcnkU1zC0sDtcKJ fH8xlZMsrVBZnhekEdoH9AUQfCIujEzzddXZsKCbrExJBK682HWlSMv10Z8bsf3D9WcPLhv6DjUB EXEWWc4fRm6AxiBRNsl..2D60m1rvLO2E6nCceYvkEAAnIvyYvT2nqQbzbtzPBWj1h2Ni6cXrx6b 8Ijcp7unQE.R3ayiFunt6iMUClLaJ.75sCZOCeh0kQliSeug3261c6A2cQzQ1ZluqPGXYELM.cQD 0sxUaFkUIIAoc0gt09dd.fxUyb61W_My4Z1QEBBtTNrAd7TVebobwm8yFrudhQfsSn_yOSuuFDQU CRGAv_rl6dDCx7P3fTmNEiUPsa8rfsCgi92eqgH6Z.W7GKShf8fq8v_vNGGC8yx1B5L73qLakJAP ZHLKRdSu9TREDt2Qauod4TkbiS6PZbDWIPmuiVd7AlIBWvJ2ucyVH.QaeRbvOZTjI.b4K5ix6KZA JzMPZh.0NSBEidJTZ_FqCYDm2V0VF2mH.E38u_LNYD8QDKvx0yECnUZqN73swBNAec1q.yCpaGzI uPdUmsE6w9LbL6p4QhB4bAfj4ZbL4ZjcZ3XSoEOxrvv9fnsEjET79MWq_qcR.G0yINXbZuTfFg9b tEg8g9Mk5oqwdh9lZJVbx Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Thu, 20 Feb 2020 22:58:39 +0000 Received: by smtp409.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e4fabd50e5459a402b02f5d4c5295d99; Thu, 20 Feb 2020 22:58:36 +0000 (UTC) To: "Let me illustrate..." From: Greg Chicares Message-ID: Date: Thu, 20 Feb 2020 22:58:34 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit References: X-Mailer: WebService/1.1.15199 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_241) Content-Length: 3061 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.134.193 Subject: [lmi] "Device or resource busy" resolves itself? X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 22:58:45 -0000 Vadim--Do you have any insight into this? I was stuck with Device or resource busy on our corporate redhat server; then, soon after I had begun to despair, the problem silently resolved itself. I wonder: - Is that normal? - What should I do if the problem occurs again and doesn't go away on its own? Here are some details. I was running lmi's 'install_redhat.sh' script, which I hoped would be restartable because the first thing it does is bulldoze any existing chroot. With 'set -vx', the logs show: # First, destroy any chroot left by a prior run. grep "${CHRTNAME}" /proc/mounts | cut -f2 -d" " | xargs umount || echo "None?" + grep lmi_bullseye_1 /proc/mounts + cut -f2 '-d ' + xargs umount umount: /srv/chroot/lmi_bullseye_1/var/cache/apt/archives: target is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) umount: /srv/chroot/lmi_bullseye_1/dev/pts: target is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) + echo 'None?' None? rm -rf /srv/chroot/"${CHRTNAME}" + rm -rf /srv/chroot/lmi_bullseye_1 rm: cannot remove '/srv/chroot/lmi_bullseye_1/var/lib/dpkg/info': Directory not empty rm: cannot remove '/srv/chroot/lmi_bullseye_1/var/cache/apt/archives': Device or resource busy rm: cannot remove '/srv/chroot/lmi_bullseye_1/dev/pts/0': Operation not permitted rm: cannot remove '/srv/chroot/lmi_bullseye_1/dev/pts/ptmx': Operation not permitted A previous run had failed while installing numerous packages in the debian chroot: apt-get update apt-get --assume-yes install wget g++-mingw-w64 automake libtool make ... with messages beginning: Processing triggers for wine (5.0~rc5-1) ... E: Setting in Stop via TCSAFLUSH for stdin failed! - tcsetattr (5: Input/output error) E: Write error - write (14: Bad address) (presumably because I had made some mistaken experimental changes that caused my normal user's home directory not to exist, so that 'wine' couldn't install itself...well, that's my guess) Anyway, 'jobs' said the script was still running, so I bludgeoned it with 'kill -9'. Then 'jobs' returned nothing, so I tried the 'rm -rf' and 'umount' commands above manually, but observed the same error messages as in the log above. Then I did this (not as root): $lsof /srv/chroot/lmi_bullseye_1/var/cache/apt/archives and it returned status "1" but printed nothing. My next step would have been to retry that command, prefixed by "sudo", and then to try 'fuser' similarly. But before I reached those steps, I accidentally reran the 'umount' command from zsh history, and it succeeded--just about five minutes after it had initially failed. I'm glad it "worked", but I'm left wondering why. I thought 'kill -9' would terminate the process promptly. Should I have looked harder for some sort of zombie process? Or could it be that all the processes I'd started had ended, but some kind of resource handle persisted for a few minutes and then was silently released by the OS? From MAILER-DAEMON Thu Feb 20 18:45:19 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j4vVP-0000Ba-LV for mharc-lmi@gnu.org; Thu, 20 Feb 2020 18:45:19 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59165) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4vVM-0000AL-8H for lmi@nongnu.org; Thu, 20 Feb 2020 18:45:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j4vVK-00057i-ST for lmi@nongnu.org; Thu, 20 Feb 2020 18:45:15 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:56084 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j4vVK-00057V-Kr for lmi@nongnu.org; Thu, 20 Feb 2020 18:45:14 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j4vVH-0000hv-GW; Fri, 21 Feb 2020 00:45:11 +0100 Date: Fri, 21 Feb 2020 00:45:11 +0100 From: Vadim Zeitlin To: "Let me illustrate..." cc: Greg Chicares MIME-Version: 1.0 Content-Type: MULTIPART/SIGNED; protocol="application/pgp-signature"; micalg=pgp-sha1; BOUNDARY="117431770-41-1582242311=:36804" References: In-Reply-To: X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.240.17.225 Subject: Re: [lmi] "Device or resource busy" resolves itself? X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 23:45:17 -0000 --117431770-41-1582242311=:36804 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE On Thu, 20 Feb 2020 22:58:34 +0000 Greg Chicares wrote: GC> Vadim--Do you have any insight into this? To be painfully honest, no, not really. I do think you should have used lsof with sudo to find it out (lsof without root permissions doesn't really work well) and I agree with its advise about fuser (to be run as root too). IME usually one or the other (and typically both) of these tools would be enough to diagnose the problem. GC> I was stuck with GC> Device or resource busy GC> on our corporate redhat server; then, soon after I had begun GC> to despair, the problem silently resolved itself. I wonder: GC> - Is that normal? It does seem strange that it resolved on its own. This must mean that either some process was still running when you tried unmounting it first and this process terminated of its own volition later or that it was locked by some daemon that released this lock. The latter is possible with e.g. Samba, but I don't think your server is running it or any equivalent. So it's probably the former, but I have no idea which process it could have been. Something launched by WINE in the background perhaps? But it's just pure speculation. GC> - What should I do if the problem occurs again and doesn't GC> go away on its own? Use "sudo lsof" and kill the process using the path. Killing it gently, if possible, is preferable, of course. I don't like using "kill -9" unless it's really necessary, although it's probably less of a problem with a system you can always reboot if anything starts to misbehave. Sorry but I don't have any real ideas beyond the general advice above, VZ --117431770-41-1582242311=:36804 Content-Type: APPLICATION/PGP-SIGNATURE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iEYEABECAAYFAl5PGgcACgkQBupB3k9sHobzQgCfUkfnBO7INn25ieP8NaCVyGMJ EX4AnimSQu9/kScXJm0YzWbGWctSmF/K =BnjW -----END PGP SIGNATURE----- --117431770-41-1582242311=:36804-- From MAILER-DAEMON Mon Feb 24 13:35:35 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j6IZq-0000N7-UT for mharc-lmi@gnu.org; Mon, 24 Feb 2020 13:35:34 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59022) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j6IZn-0000MI-Rt for lmi@nongnu.org; Mon, 24 Feb 2020 13:35:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j6IZm-0008AW-Jr for lmi@nongnu.org; Mon, 24 Feb 2020 13:35:31 -0500 Received: from sonic315-16.consmr.mail.bf2.yahoo.com ([74.6.134.126]:44403) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j6IZm-00084C-Bj for lmi@nongnu.org; Mon, 24 Feb 2020 13:35:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1582569327; bh=iWOngX8vedq8fXb1ZOfeUroG8rgicucFWjm+pkfAoO4=; h=To:From:Subject:Date:References:From:Subject; b=lxcvu6l6rfsL7qpygRiHwTE21z8/DyOM5sK9b26Sd/Rc25NFEwpIr2E5OmHav1OM6w1AdwJQkHsiOxmpn0DlEpVU5Mfz5vGf/pBGuXpv69p5+sFjPHFs2mYSWhd+e5xdDBxA9nQbsRU4TsPk/sRgtIE+XkCaKuHsi4xrmzE2DoRDt7FCG4DRpmO93A55n2lOKAgsEwPNNd81UTfUwsMmBZre+2gQztmn0jzibikBFFFRT+5iNvDT5ngHWoIvr8R6WDG+mxDjFiU+AtHqi5UBpoaqyencly4Lzxu9cda1IwWlCUReTKdvdzR0Wg1Nnv2e2grJAm5EGOyLDRdVa4oUng== X-YMail-OSG: 0TxmMaQVM1n.JrbFR9HfNdUtMzu6X6G5Wq0VeC5AcR2kXx3UzV0.5n4uhi5bMtf LNC9CTf1oBOYZg0ul1BGai7CtSCGlCMJPthN0dLMsUY.9nvGs.g8f_E_1HqH2ZX_hiBnii9lpiwH UGQDlcuOd1s6GpPOLFSnbhhpy49cJVxaujQTJ3YxbkvKjHxuvLi3tcMKN0CNr63VbVDrfU7DbyI6 mMSf6jco299KxXZF2H7Ua_PyUCjlvAu6t2k2yGWjZtE5opmfTHgPelW20VQLMYsWoP6hFzIWt0xq ONETPyybYQ4kTYZOUzQ0A34IIwy4bcHrW1KA.tu0mUsVXnEsKILQiB1a0QqFUH40VSOOC.DiAEh1 QbDoi_L0FBqFSYiheccEW71kRuYKPtX2LtNInUKPcKsKFtjASc4amDRmBvY9YXgfq1ONLX1BY2p0 fnUgkR.GBE4Po6fOtN9f3hyIgqk4bisdENtsiGP9LVFDRhjRqKhOVa1nJYvW_hmYKBqOXHlWDIN8 OkQJ.NTw_vgcjiiZdChmxsheyGVKbDmDJ.p6s2vvgnEbjjjRy5G5OXpOF0ydye_GMcnE3tywYEXe TwxlHPEikl0fqilqmcWJeBsi.HRGT.g4w4QPfxJ99_auy8tUJO5e2xQ3P3lG2z5s_RfF6jFBXj6_ rkCuygWcUELwLs5jKrftzwQLHVHYRqgb40Aoy02XkuFVrwnbhrfqd7vE55K9Wmo2UKxuHENku38R oyiOamBvF_.kBCuuhU3SlMv5wHxaVoMfzNirL11j4olZXZ5DhHrAb3Q55sF3OEhn.w_5Mczh1.D8 oQ2zg_qkNeN2WwXd3TSsv1Zljdap9H13aGkMkU7etqtY.LXjuB2TIv1NFRYhNT.n710dFY8K7xUU 7JqS1MfbCABr.SfSxzt1dl.joFFfnNJd3QuJULA4rOH6KETRKmu.Ju3ApZrVRUKq9d6pWODbva9A Pvr82zI.J6JDm.1A1vwhqOpnQrSybLvFLCYVlCLupeT0cd.H.PqMZurME7NMby0bhb63gbxMVA0Z _4dceFKbsh.2Qq2uMCh5ZeVh1m0Pg0.5eLVgZ02dJySbrr_SaVShYCxgXw5elIywSQoQSbjvV46N pyovtZ1Pk1RMuQ9wbOLuVUcFqCjPSU.HyEQhqDcEAVFVe4uqjKPxZ27ADQCO3kAcSjg1l53OHLRM R_MIbIoSgvTfjhVDTE4YdBDSqLDUV1XBmGO5VZtWXBbsh1S_gC5DMHAoY4QWXXBQP8HXwnRXEEes QI6tkNjnC81NAcdFwUPLjhl0EQ75.IPByvbk.eFmNsz82GaFpBvrWmGw5394azTu1cgIiXiJvBoJ U9g7R9RO0IEQnxf8pShCt_DZ7W4VAXlErvu3954Se7.ANbATL5IpLfNYk.XKyLBjuwzHn2gpJoYz g9n4lvHMf3bxlpPdjBvlOhO4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Mon, 24 Feb 2020 18:35:27 +0000 Received: by smtp422.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8b3a52270511a0f4b0a545a2ba3d1496; Mon, 24 Feb 2020 18:35:24 +0000 (UTC) To: "Let me illustrate..." From: Greg Chicares Message-ID: <8bbb7b9e-851b-91ab-bcb4-5e91eb16e3e2@sbcglobal.net> Date: Mon, 24 Feb 2020 18:35:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit References: <8bbb7b9e-851b-91ab-bcb4-5e91eb16e3e2.ref@sbcglobal.net> X-Mailer: WebService/1.1.15199 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_241) Content-Length: 2530 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.134.126 Subject: [lmi] logname fails X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 18:35:33 -0000 If I sudo [... whatever] schroot [...whatever] then 'logname' returns my unprivileged login name on my debian machine, but not on a corporate redhat server. See this branch: http://git.savannah.nongnu.org/cgit/lmi.git/log/?h=odd/rh_server The only purpose of this email is preemptively to answer the question: "can't you get that information with pstree though?". Here, I'll just use ps directly, because I already have that installed in the chroot. First, debian: /[0]#ps -p$$ -ouser,ppid,pid,comm USER PPID PID COMMAND root 1460 1461 zsh /[0]#ps -p1461 -ouser,ppid,pid,comm USER PPID PID COMMAND root 1460 1461 zsh /[0]#ps -p1460 -ouser,ppid,pid,comm USER PPID PID COMMAND root 1455 1460 su /[0]#ps -p1455 -ouser,ppid,pid,comm USER PPID PID COMMAND greg 1448 1455 zsh /[0]#ps -p1448 -ouser,ppid,pid,comm USER PPID PID COMMAND greg 1 1448 konsole /[0]#ps -p1 -ouser,ppid,pid,comm USER PPID PID COMMAND root 0 1 systemd So I am still 'greg' after all. But that doesn't work on the server, presumably because it uses LDAP or something [I've obfuscated the output to hide my user name and UID]: /opt/lmi/src/lmi[0]$sudo zsh /opt/lmi/src/lmi[0]#schroot --chroot=chroot:lmi --user=MY_UNAME --directory=/tmp $ whoami whoami: cannot find name for user ID MY_UID $ ps -p$$ -ouser,ppid,pid USER PPID PID MY_UID 5178 5179 $ ps -p$$ -ouser,ppid,pid,comm USER PPID PID COMMAND MY_UID 5178 5179 bash $ ps -p5178 -ouser,ppid,pid,comm USER PPID PID COMMAND root 4419 5178 schroot $ ps -p4419 -ouser,ppid,pid,comm USER PPID PID COMMAND root 4418 4419 zsh $ ps -p4418 -ouser,ppid,pid,comm USER PPID PID COMMAND root 4152 4418 sudo $ ps -p4152 -ouser,ppid,pid,comm USER PPID PID COMMAND MY_UID 4151 4152 zsh $ ps -p4151 -ouser,ppid,pid,comm USER PPID PID COMMAND MY_UID 4078 4151 sshd $ ps -p4078 -ouser,ppid,pid,comm USER PPID PID COMMAND root 1727 4078 sshd $ echo $LOGNAME MY_UNAME $ id -un $LOGNAME id: 'MY_UNAME': no such user $ whoami whoami: cannot find name for user ID MY_UID So it seems that, with effort, I can get my numeric user ID, but I can't get my alphanumeric user name. And I'm not in /etc/passwd , so I can't just look it up there either. The next thing to try is to move from a 'plain' schroot to another type that supports setup scripts (as we probably should have been doing already, anyway). From MAILER-DAEMON Mon Feb 24 14:38:23 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j6JYc-0006AW-Sh for mharc-lmi@gnu.org; Mon, 24 Feb 2020 14:38:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38753) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j6JYY-00067R-DP for lmi@nongnu.org; Mon, 24 Feb 2020 14:38:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j6JYW-0002IF-PF for lmi@nongnu.org; Mon, 24 Feb 2020 14:38:18 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:53846 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j6JYW-0002EY-Fu for lmi@nongnu.org; Mon, 24 Feb 2020 14:38:16 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j6JYS-0007ok-Tw; Mon, 24 Feb 2020 20:38:13 +0100 Date: Mon, 24 Feb 2020 20:38:12 +0100 From: Vadim Zeitlin To: "Let me illustrate..." cc: Greg Chicares MIME-Version: 1.0 Content-Type: MULTIPART/SIGNED; protocol="application/pgp-signature"; micalg=pgp-sha1; BOUNDARY="263067932-41-1582573092=:7932" References: <8bbb7b9e-851b-91ab-bcb4-5e91eb16e3e2.ref@sbcglobal.net> <8bbb7b9e-851b-91ab-bcb4-5e91eb16e3e2@sbcglobal.net> In-Reply-To: <8bbb7b9e-851b-91ab-bcb4-5e91eb16e3e2@sbcglobal.net> X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.240.17.225 Subject: Re: [lmi] logname fails X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 19:38:19 -0000 --263067932-41-1582573092=:7932 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE On Mon, 24 Feb 2020 18:35:23 +0000 Greg Chicares wrote: GC> If I GC> sudo [... whatever] GC> schroot [...whatever] GC> then 'logname' returns my unprivileged login name on my debian machine, GC> but not on a corporate redhat server. See this branch: GC> http://git.savannah.nongnu.org/cgit/lmi.git/log/?h=odd/rh_server GC> GC> The only purpose of this email is preemptively to answer the question: GC> "can't you get that information with pstree though?". I hadn't thought about this question, but I did think about 2 other ones. First one was related to the comment in the commit above: could we solve the problem by defining some LMI_USERNAME environment variable which could be inherited by sudo if its "-E" option were used, and would, hopefully, be propagated inside chroot too? This wouldn't be dependent on user home location. Second is more directly related to your question above: it looks like it would be much simpler to get this information from /proc/self/loginuid than from pstree output. AFAICS this file is the real source of logname information anyhow, as logname(1) is just a thin wrapper for getlogin(3), see https://github.com/coreutils/coreutils/blob/2ed7c2867974ccf7abc61c34ad7bf9565489c18e/src/logname.c and getlogin() itself gets the user ID from this file, see https://github.com/bminor/glibc/blob/5f72f9800b250410cad3abfeeb09469ef12b2438/sysdeps/unix/sysv/linux/getlogin_r.c GC> So I am still 'greg' after all. But that doesn't work on the server, GC> presumably because it uses LDAP or something Whatever the server uses, it's still misconfigured if it can't map the user ID to the user name. I don't know if it helps you whatsoever in practice and suspect that it doesn't, but I wanted to mention this just in case it could be helpful to complain to the system administrator about it. OTOH a quick web search also found this question which might be relevant: https://stackoverflow.com/questions/18570177/getpwuid-returns-null-for-ldap-user It dates from 2013 and your problem is definitely not due to lack of 32 bit libraries, but I wonder if /lib64/libnss_sss.so might be missing on your system? GC> So it seems that, with effort, I can get my numeric user ID, but I can't GC> get my alphanumeric user name. I guess you could use some horrible hack with "ls -n /home" and selecting the line using correct UID, but it's rather painful to even think about this... Good luck, VZ --263067932-41-1582573092=:7932 Content-Type: APPLICATION/PGP-SIGNATURE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iEYEABECAAYFAl5UJiQACgkQBupB3k9sHobhLQCgjUtEQkOREYHW0r7l7YjWasDL PmEAn1BgkaZLet+vpvh9DLLHobcTLGDI =18y9 -----END PGP SIGNATURE----- --263067932-41-1582573092=:7932-- From MAILER-DAEMON Mon Feb 24 19:21:53 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j6Nyz-0000Yh-7R for mharc-lmi@gnu.org; Mon, 24 Feb 2020 19:21:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52168) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j6Nyv-0000YR-Vf for lmi@nongnu.org; Mon, 24 Feb 2020 19:21:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j6Nyu-00068E-Mw for lmi@nongnu.org; Mon, 24 Feb 2020 19:21:49 -0500 Received: from sonic312-25.consmr.mail.bf2.yahoo.com ([74.6.128.87]:34475) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j6Nyu-00067d-E1 for lmi@nongnu.org; Mon, 24 Feb 2020 19:21:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1582590106; bh=mM1LW4sJhGZUNFZ2/tI2q4yhUvFkqX3YcvpvB6xhzTI=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=lZQc1Wpu61wai7+EyUoMxJFzunLBWBFXgspXfkWGpLoJvzv6PJaiNxk+rqOhtuPdhtotqY3VzeNvFekIh3j3pOpmt2W4u0fGofAire9zCQ3jItDtXYcMVMvCpx4rDMj9JSYjpH0fvt1pR0pMYG1oF7HbcVGgmKIa0Yp/AjYwigQvVRpe3nSH+fIVZKQdbb4JkHt9JZdex/qG+tMHhQoWQHMwHhDMD1E1C2UQmLpDA1y1Lv/GXXDp+A9dlTACt0fZq/efh/IrTew1XbbRguNLMe1GTWp3XGd9sT0RMPA+B7jGp/z1kTV4R7Bg2SttAjgr4CE+s9yOl3Lnd5Z5WlU1Dw== X-YMail-OSG: _xkFUSUVM1nIOEvUDh8cauDjZ3uxG8Wo1MXLqcMkzLQWPUCBpljGeLXmotZ76Hw tWPgVZp.zAhw8FjleTC2t1pXkwTfmTvqL4_OOrEIZvxGlE8D6AaQk_A_s2UxomH_Rnd2nejPCSN. UQJbtyTkL0uPaZ43tkxU6CznUYcPAn2ZMSWOlgYJiCopEUzRpzJ2EaoQfjFphZcflU4Tttem4ZGm QTjTBhdsS6mggns7xLeXg012ivEwVvma8vX6lC6.9ejwzcsSMo5KwSnY6YIWI1bDIYmWWjclrmZn 4YpMaxjfOrpYnLs0Qw2SKaDfhl8sDmZ9FbSZoTzV.YBFbJIBFJtzi8_Rrj63vYqGaAzsbLNql5DA JaSbeYennsmNLrRQ32rZ3cTZeO52uvz7fXwuZ8Xjk42Iv90YvoLnXGpCU046iKVIGqlTp9ieXGCp Ljyif04bGMMevypVM6bMpx2eOINGzfu8ajk0.Yjpwi.w0EgTk6V3J2awteUB1zmJNJNqdl_mzcy4 DbXivktw7oYwTFrpDIkPQXV6Z_0Flmx3u19UmVkGWoKFnnMKh7OZWuRXiGf78f7zY7o2UE9tE93z ACFZuvvG.BIBMtZvcMtlJssXRWuTEIf7aixN7BPpjSLfQDB_VModkrvDdi7QOeFHYBdy7M0iU2AX eR3ybgentmoIRh3QeoF8ZfcFSV6_WIUytJoLflMUSjzbKL_Mq3gnrReLRvbBBVvURt59RbFV9m37 ldlHGxzbeT5CNzg9kLIsoCosxv7_VZ05fEgFcEStsC390xhdnjSXn2y8bRyirpvnCE7y4MdIUZ.M FQEmUdyjOuZI7slIhjlpRWqnoq7UYuWgloB2u0AsGfkIV6u_GK4xK587f8w5CppKPx92poYIijbs y0Sd3dvBnKORqp3wC64QJM5nnZOwO1LCBDQMYeabWtgcSMjSvfrgCFoEC4fW8H.Vs0b11zyUTk98 4eelS1lwDJb9gjNrDGNisNhhLhovSfKXpvH.n5YxX4CbsY0VS4q3M2x.H0UJyP89luSrjPu7yuMb e2UVIRr.ZvJL1N8mkZkVzWZ4oHBOsLrDk4WIrOUuex6DirZ7FRTUU0FAW_Na5UQuMlaxPuLsjb1c C05yQQyjeOn3svGK8_nGdg8AqgUR4KX8SK9zzDGjZ3vThq9fUgRyqksNbD0POcT803vZCyHTTtlv r_.b4BdObcj9s7QVgNJdUIHCMcYCb1vWq2IQhdFsu_yJbI4g3Fbwd67pmPGW_8PJz8r40YqbmfBB Q.pE3r6.pETn98jgHnaV6nPBawTZwi.9feDg0_tXGKtwPKx3_VFcnpF.FalsZe9sIGRiyuofF5Hi _gxFkqrlKFCXi9FnkWbIHGUNlysF.GgXpbS3x..vpFXyNuY6eCB5BD4BWZaTYX5dxSL1yHvOI1oM 6DCE0A0glDOsWHTXdc15NVoUsav8- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Tue, 25 Feb 2020 00:21:46 +0000 Received: by smtp417.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 529a04c2f9589bc49639bcaf48b1042d; Tue, 25 Feb 2020 00:21:41 +0000 (UTC) To: "Let me illustrate..." References: <8bbb7b9e-851b-91ab-bcb4-5e91eb16e3e2.ref@sbcglobal.net> <8bbb7b9e-851b-91ab-bcb4-5e91eb16e3e2@sbcglobal.net> From: Greg Chicares Message-ID: <8ee61206-8884-a425-b5d3-b7148a796dbb@sbcglobal.net> Date: Tue, 25 Feb 2020 00:21:40 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.15199 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_241) Content-Length: 2852 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.128.87 Subject: Re: [lmi] logname fails X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 00:21:51 -0000 On 2020-02-24 19:38, Vadim Zeitlin wrote: > On Mon, 24 Feb 2020 18:35:23 +0000 Greg Chicares wrote: > > GC> If I > GC> sudo [... whatever] > GC> schroot [...whatever] > GC> then 'logname' returns my unprivileged login name on my debian machine, > GC> but not on a corporate redhat server. See this branch: > GC> http://git.savannah.nongnu.org/cgit/lmi.git/log/?h=odd/rh_server > GC> > GC> The only purpose of this email is preemptively to answer the question: > GC> "can't you get that information with pstree though?". > > I hadn't thought about this question, but I did think about 2 other ones. > First one was related to the comment in the commit above: could we solve > the problem by defining some LMI_USERNAME environment variable which could > be inherited by sudo if its "-E" option were used, and would, hopefully, be > propagated inside chroot too? This wouldn't be dependent on user home > location. That's less ugly than walking through ps's PID->PPID chain. But it replaces restrained ugliness with brutal elegance: using '-E' feels like poor security. OTOH, anyone who has my 2FA credentials can sign in as me and run 'sudo' with any arguments at all, so I guess I shouldn't be concerned about this. And actually I can use the equivalent 'schroot' flag: $ sudo -E schroot --chroot=lmi --user=root --directory=/tmp \ --preserve-environment env |grep "$(logname)\|$(id -u "$(logname)")" That command gives me SUDO_UID SUDO_USER SUDO_GID but no group name. Still, the "type=plain" schroot that I've been using is no longer supported, so I need to figure out how to use at least "type=directory" anyway, and then: - I should be able to pass data like this with '--option', and - directories like /proc can be mounted by schroot so that's the route I'm pursuing. > Second is more directly related to your question above: it looks like it > would be much simpler to get this information from /proc/self/loginuid than > from pstree output. When the only applicable tool one knows how to use is 'ps', then 'ps' becomes a Golden Hammer. Thanks for expanding my repertoire. Still, there's no /proc/self/login_name . And what I really want to do is enter a newly-created chroot as root and run 'useradd' with my login name and UID, and then 'groupadd' likewise with my default group and GUID (or group "lmi" and its GUID on the redhat system). > OTOH a quick web search also found this question which might be relevant: > > https://stackoverflow.com/questions/18570177/getpwuid-returns-null-for-ldap-user > > It dates from 2013 and your problem is definitely not due to lack of 32 bit > libraries, but I wonder if /lib64/libnss_sss.so might be missing on your > system? It is present: $ls -l /lib64/libnss_sss.so.2 -rwxr-xr-x. 1 root root 37168 Oct 9 08:23 /lib64/libnss_sss.so.2 From MAILER-DAEMON Mon Feb 24 19:37:31 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j6OE7-0007AO-CR for mharc-lmi@gnu.org; Mon, 24 Feb 2020 19:37:31 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53688) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j6OE4-0007AB-Kc for lmi@nongnu.org; Mon, 24 Feb 2020 19:37:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j6OE3-0000Sb-6s for lmi@nongnu.org; Mon, 24 Feb 2020 19:37:28 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:56792 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j6OE2-0000R9-Vl for lmi@nongnu.org; Mon, 24 Feb 2020 19:37:27 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j6OE0-00011B-5v; Tue, 25 Feb 2020 01:37:24 +0100 Date: Tue, 25 Feb 2020 01:37:24 +0100 From: Vadim Zeitlin To: "Let me illustrate..." cc: Greg Chicares MIME-Version: 1.0 Content-Type: MULTIPART/SIGNED; protocol="application/pgp-signature"; micalg=pgp-sha1; BOUNDARY="281018847-41-1582591044=:7932" References: <8bbb7b9e-851b-91ab-bcb4-5e91eb16e3e2.ref@sbcglobal.net><8bbb7b9e-851b-91ab-bcb4-5e91eb16e3e2@sbcglobal.net> <8ee61206-8884-a425-b5d3-b7148a796dbb@sbcglobal.net> In-Reply-To: <8ee61206-8884-a425-b5d3-b7148a796dbb@sbcglobal.net> X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.240.17.225 Subject: Re: [lmi] logname fails X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 00:37:29 -0000 --281018847-41-1582591044=:7932 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE On Tue, 25 Feb 2020 00:21:40 +0000 Greg Chicares wrote: GC> On 2020-02-24 19:38, Vadim Zeitlin wrote: GC> > On Mon, 24 Feb 2020 18:35:23 +0000 Greg Chicares wrote: [...] GC> > OTOH a quick web search also found this question which might be relevant: GC> > GC> > https://stackoverflow.com/questions/18570177/getpwuid-returns-null-for-ldap-user GC> > GC> > It dates from 2013 and your problem is definitely not due to lack of 32 bit GC> > libraries, but I wonder if /lib64/libnss_sss.so might be missing on your GC> > system? GC> GC> It is present: GC> GC> $ls -l /lib64/libnss_sss.so.2 GC> -rwxr-xr-x. 1 root root 37168 Oct 9 08:23 /lib64/libnss_sss.so.2 Disappointing, it would have been nice to find the real problem using nothing but my deductive reasoning and all the information available to Google (let's not quibble about the relative weights of these components). Still, I just can't believe there is no way to get the user name from the user ID, does "ls -l" show you user IDs instead of names too? Also, I've realized that I didn't know if "id -nu" didn't work only inside chroot or inside the main system too? If it's just the former, maybe the problem will get resolved by switching to the new schroot kind, but if it also fails in the latter, I'd really consider using strace/ltrace/whatever means necessary to debug and hopefully fix it. Regards, VZ --281018847-41-1582591044=:7932 Content-Type: APPLICATION/PGP-SIGNATURE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iEYEABECAAYFAl5UbEQACgkQBupB3k9sHoZKogCeKyD+MHSMFHvpNoROtpJSfFEQ EBAAoJdX3bKAly4KCUNvhDs+rwfoLySB =IzhW -----END PGP SIGNATURE----- --281018847-41-1582591044=:7932-- From MAILER-DAEMON Tue Feb 25 12:40:05 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j6eBh-0007eO-8D for mharc-lmi@gnu.org; Tue, 25 Feb 2020 12:40:05 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35688) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j6eBd-0007e0-VV for lmi@nongnu.org; Tue, 25 Feb 2020 12:40:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j6eBc-0002T1-O5 for lmi@nongnu.org; Tue, 25 Feb 2020 12:40:01 -0500 Received: from sonic317-29.consmr.mail.bf2.yahoo.com ([74.6.129.84]:33170) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j6eBc-0002Pf-Dn for lmi@nongnu.org; Tue, 25 Feb 2020 12:40:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1582652398; bh=SaI2Xrnlf08yb9MQZ65iUtXrawZb6JlT1xRor4OTP5M=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=ZHsENi10oh92t62aAU4hQ7+DWIrOvS8pGQxbjFfSz3o2H5Iv5Qr2JrbzsUN8cQmuj5GOzgls3Ck0sytwJvKo3Wz1U74TlaxVL424X/wcZictzE6VOTYQekb1ZVvGVBHlrFjnfa6nJSDTY5diovSpu0RkWdgj6nsRlN5HJ8N8mvDp4K5j/COcQDvmueld+EEhuJ3o/kyfOpT8PtVeN7m7GLhJCnU3bS9Su870FxztiQivJNb1fTf7Jb8ATryEzo/30nOp1xD69VYixYPxDB22eBkgBWJzXIneeXxkE0cW6tr/pTyMgWN+3P6j5zOOVD61Mqr8r66KSIK5PwoBAHzbmw== X-YMail-OSG: uST_lp0VM1nwcwXrldASV4vz9GKRiPvj8izJfCfFkr96Kn4.BE0gLr9ZlvykTgQ ByrDOkBTGMMy8HvJnkKglrcT_DXKEX5OopV1TukeUh6vQUWy5AARLzvQKK3s4xVoYFNgZ58FKqUg gnbf36.uFW2zzSSGEKyyscxiqXt5o4Wf2nHvvnChYUvKyb86274MH.t9g2n1OCu8vgVRq56fFdZc G_YcbOoN_akQrzTGKIG9KTNdwUAjvSv5rV2L26vzKvAMEBbpDsLKwe5.b_NBpkVSkrnK4USQ8ZBp CxLXkvIct34pZ0F3UhKlmp1dkZbi8XZ_K7biwpmMZxr5MvW7CuS00sifIRQ1SlhyWtQGFBnxaqYq euejnkym8xvp94g1kkMWVCqnVAJtF1LDOIwCwfMIt88BzgrZDfrjAQR7Tci1.O2WRzziR9fFC9TI vbEKh8nov0haJBg693gwYnBfgcOqc92zM5W9Ih2lzsTCgP6_0qnr0EOMs8H9XzX9Lh7QES7_PlvY pf9IS6kq0XM0tQVtGZ3_iJlli7q8IZ69DmbPdyMdS4SJ5xXpwuTtPI8pJDuGufZ0YBBkYCztC6Iv XhKs83eZADo9Zu0OvxK27nklIyEE1eaS_sF9cJ0eBNLaN4Kccj9PMb1FX.KUqvuga7assdbYs71i pJrgizdPN8i1axbojDLVdUaYjS8WUaOLUEiung4XVv0JGgQMf8EJITXiR.fFY1.3E26TfruOk3Mf gxoE2H0SOz93gXKdrPOc31RyL_vbZ5P..Q24z1RixDIMJbMHmgT3UAJo2fVaE.VNKYKcI.FFOesZ faInPkqCceH9x8bgvmP.JbaUnmN0Yi_w17VjCGRoAAQ.sI16gcUPzkXKIMgsZZutJGmnwimilScH bqidjn6pweBkVhoeUQ_HPM7VY7m49CekyJdlJ.uWyXbcuaB.oPqkjZrWp9CI5u3Jmjnl761Mk_4j bgHPGl.d0KNS5cAAtkbjHSmnOK3KI_YVjaYOFZx4Vp9vL7zHYGEpT.L0Yd.SNbHAQvxz_mqr6oAw _T_9yVCuFi47xXQ2_iN0ITUGyfDPqRia9E6BizG6wPqysRpfR3P7uIinZ7w4UEg8Q.q1OpGXqjiv 3McR3FAUn1THlmcNlPHQeUXxPiHGe3Y7zhbtyPzUKtkRp6rExaUyBRvwDGhtchEUc6AP7yRBX_mx sYjExwouRVd4zDXGAbk4lI5tPOhAy.f0auo8HmuKd7Izpim_Os7fg_FbMSSc50zl76AOjxgSfQsM GlEp6mbB2JwX_ju7Xz99KT1GaiVZowLwn3DtCVJQWtH68c89rN0NAzhzyH_Wph4Y7FygrE5DsjE8 fiXUGnJqBxH5qtNVVSBR0WavIMDMDaZtghWD11sAjl_ZH5eISs7EaWHW76.OR6oz_XtzOjAE86g8 PYuHBX0nIh5iQOB63qSBYkg4u Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Tue, 25 Feb 2020 17:39:58 +0000 Received: by smtp405.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID dc962e92341c31c0e24f98d09c05adb3; Tue, 25 Feb 2020 17:39:53 +0000 (UTC) To: "Let me illustrate..." References: <8bbb7b9e-851b-91ab-bcb4-5e91eb16e3e2.ref@sbcglobal.net> <8bbb7b9e-851b-91ab-bcb4-5e91eb16e3e2@sbcglobal.net> <8ee61206-8884-a425-b5d3-b7148a796dbb@sbcglobal.net> From: Greg Chicares Message-ID: <683ee240-f4f2-c782-6011-1303b4ccb789@sbcglobal.net> Date: Tue, 25 Feb 2020 17:39:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.15302 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_241) Content-Length: 2854 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.129.84 Subject: Re: [lmi] logname fails X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 17:40:03 -0000 On 2020-02-25 00:37, Vadim Zeitlin wrote: [...] > Still, I just can't believe there is no way to get the user name from the > user ID, does "ls -l" show you user IDs instead of names too? Also, I've > realized that I didn't know if "id -nu" didn't work only inside chroot or > inside the main system too? I observed that failure only inside the chroot, and more specifically, only when root enters the chroot as a normal user, as in: $sudo schroot --user=unprivileged_user_name ... I've observed it only where 'schroot' is involved. I don't know what would have happened in a case like $schroot --user=unprivileged_user_name ... where an unprivileged host user enters the chroot as an unprivileged chroot user. Thanks for continuing to challenge this--it's led to a surprise. I hadn't thought of checking what 'ls -l' prints, so, in order to try it under exactly the same conditions as before, I consulted this email: On 2020-02-21 23:18, MY_CORPORATE_EMAIL_ACCOUNT wrote: | /opt/lmi/src/lmi[0]$sudo zsh | | /opt/lmi/src/lmi[0]#schroot --chroot=chroot:lmi --user=REDACTED_NAME --directory=/tmp | $ whoami | whoami: cannot find name for user ID REDACTED_NUMBER which I'm absolutely sure I copied directly from the PuTTY screen. Cutting and pasting exactly those commands, today I observe a different outcome--everything just works: On 2020-02-25 14:56, Chicares, Greg wrote: | /opt/lmi/src/lmi[0]$sudo zsh | /opt/lmi/src/lmi[0]#schroot --chroot=chroot:lmi --user=REDACTED_NAME --directory=/tmp | $ whoami | REDACTED_NAME I can't really say why, but I can speculate: (1) Some sysadmin has done...something. I doubt that: sudo who --all shows that the system was rebooted 20200219, but shows no login by anyone but me since then. Nevertheless, I've installed etckeeper so that I can examine any configuration changes in future. (2) RHEL is somehow unstable, which would be surprising, though maybe there's an external LDAP nameserver that was in some undefined state for a few days after the last reboot. (3) There's an unknown defect in 'schroot'. Or, more likely, some experimental iteration of my setup scripts had set up a chroot in some improper way that 'schroot' doesn't diagnose. AIUI, 'schroot' makes some attempt to duplicate the host system's users into the chroot's /etc/passwd , and maybe something went haywire there. That would explain why calling 'ps' repeatedly from inside the chroot couldn't find my real user name. Also AIUI, 'schroot' was created for use by debian maintainers, who probably don't do much testing on redhat. IOW, my guess is that the difference between the 20200221 failure and today's 20200225 success is that they used two different (though identically named) chroots, and that last week's had been created by a script iteration that had failed to create the desired unprivileged user in the chroot. From MAILER-DAEMON Wed Feb 26 17:27:24 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j759I-0008RP-E0 for mharc-lmi@gnu.org; Wed, 26 Feb 2020 17:27:24 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59227) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j759F-0008P1-I8 for lmi@nongnu.org; Wed, 26 Feb 2020 17:27:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j759E-0003p3-1v for lmi@nongnu.org; Wed, 26 Feb 2020 17:27:21 -0500 Received: from sonic312-24.consmr.mail.bf2.yahoo.com ([74.6.128.86]:33900) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j759D-0003PL-LD for lmi@nongnu.org; Wed, 26 Feb 2020 17:27:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1582756034; bh=lfMnebp4+NZSRuxqVyKlRVxcq0d1KYpUiJKzyb7EPuI=; h=To:From:Subject:Date:References:From:Subject; b=iVI19yIw9zf5OpBw+cdGmeMyhValfUGR/LltT+xqwTqUfnhixOrNV1Bm13lO9nxZ67hbEqq8NcI/355Q2HevwIDOMcVppyjsYD1SGIEmRn8eWTm6y4bFzSoRV+tUcFQCJbia+fdBaaEcOWjgTX8B1DteOig1PAo8j6ETLx8ATpNOAlQQP0mPwIVKALf7oNpz1QuNIU9oFiCYXISWGd7ycC5mfNX8ChKtvKCSMOTUZOBoI/vwCMpePBn5rBQvgHWlObA8UDtrqZyWG1t6ms3PfhPWa2oPOxzZ1Hq9cUf5FZnR1cBZ1YQREGfs72ES6asDvEvDCBX7k8ycqYvX/6bErg== X-YMail-OSG: Yz6OLdUVM1nM_eFCkwZ12wzFcg_t9pEc1ux7y_ZzlmSI6SrDUNaxnaGoaevZAt7 oWS9DZDIfI4oEYxo6qpDknLO6K5ZFO9Wb7dJrI4Vw8gSQWyIegVTgAgbxpvA.zbhQa.gJxnkBVoe MP.KuDnaS4rSYYEkm1HywRmx7XrBCuB1.zVZsZHbZSxeHHX554xTCNaAwL8_RKMIoxdkEsK74Hmt NOfTOdgQ7nxCJRZpjz9DZcGUZ9gC3FRB1h6Af760VNEnIBokDnErznVMqNbPNEiA1T9eDddtwrJE JnO9b72erB4KclXsuBVMdC12YtZQeX9Q2VNb4rP1hYYLT1n2PYrvAx3_BkGbp6mdOnMV4WE_1kOl skAtt2fTRHZlWtS_RE2WiRDyoK44ruXR7ZeOdhWq3rWvD1XgoENBR2IGYG6rQHa2kLNIuJzwulrP eWOCgcO7HDCbYu9BRVEjvC5ru81eIzC17ccLLHkvekQML9SNSXoKXWB4NX6z_6SXmqTIQRSc6DWo DJlP.7R1U3kNPbkzH0DB9EvthBFEIePsGp48cmz5e3qXpwcyPXkmJ.gFI6Jl9f1bb7e2O2b.S9Sz z4Jg00Qb2S98dIZpjuSn_Lp.868wTwKnXkIBAXB6WurUHa2xUQ5o1g9mPukEjlTQqB5yacEZaCcd 14PbiPu.X6WmDfmJUP5.3szyuZ5lOK2rGY7XsBoVtgCtZsa5oQPy2LYQbkeUbwFJ.RR5PtU3QCc_ lPAvdlvaKvrf_L3vscRvqXwNuEe9PjP4hS4wshI_RIzOMBnH3vUKoiA_hsKMTJyc2kfs6TYHlnVg o1jxyjXc1j6TdJeydFAFrOTsYUm6f9IQICzfaphTmZyWpBSkH0AcCn4oovJOQL6DcqeGX8hK8zlr yXbKXAGb.pDWLeZubcqgT2MlEp4lBLBGrj4a6xhjkfHdSZFDlqFS4neUJUZjhf3JO2RP0myNGd2a UM6SupJOlh1i9w4ZVIvkN8ypDzY_3tSudjnYFScde8j2615qa_PmXGZL4UnePnmKy2LmXt8HuIu3 YwVZCmrgr__GyixpyKNlIX_2M9_8LeBDGnlXgh_5WhhJ2u.gsn6O4z6V9fLD_I4Fv3Hhc3g8.95i bBlI1qJBQzbpIBh47SDBrCCZMjRzeYByDzpYKPPJ1zIOUH2j0JsDWrV9mBgqfUmeDJDVdFLkTdAi 3NSFkE4WDMoX7hwIT7Vy0qZzZnaYEwM4wqnV7YCuX8GQ_msgufI3BTcJc9BYxAZJ2Tq2zxb1IzNH Fwq2NXsB0JWmOIk9vYZgX02DZ6I6f24g0fYJM7MScP5.LArM3HNj_igXawfbL54yL0wz6U.w7tWp lf0.hIZUWQMsmyQ4wsevmnynk7yYxX1R5FhjUGgzxztaEjL0bvIFYkburDPL.0x2VGCrHyraCJNd EewOvH2AcNI84JpCnYCEaQZTHaw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Wed, 26 Feb 2020 22:27:14 +0000 Received: by smtp431.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ee51c0052ffaf13685567c3680584c64; Wed, 26 Feb 2020 22:27:12 +0000 (UTC) To: "Let me illustrate..." From: Greg Chicares Message-ID: Date: Wed, 26 Feb 2020 22:27:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit References: X-Mailer: WebService/1.1.15302 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_241) Content-Length: 566 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.128.86 Subject: [lmi] Shell scripting bafflement X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 22:27:23 -0000 Vadim--Sorry to bother you with this, but I just can't see why these two nearly-identical commands behave oppositely, and I'm sure you'll know why. This does exactly what I expect, as [non]gnu.org is certainly reachable on my machine: /home/greg[0]$if curl https://git.savannah.nongnu.org:443 >/dev/null 2>&1 ; then echo true else echo false fi true But if I enclose the command in "[ $(...) ]", it "fails": /home/greg[0]$ /home/greg[0]$if [ $(curl https://git.savannah.nongnu.org:443 >/dev/null 2>&1) ]; then echo true else echo false fi false From MAILER-DAEMON Wed Feb 26 17:37:36 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j75JA-0002yj-6z for mharc-lmi@gnu.org; Wed, 26 Feb 2020 17:37:36 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34573) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j75J7-0002y9-6i for lmi@nongnu.org; Wed, 26 Feb 2020 17:37:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j75J4-0006az-Bq for lmi@nongnu.org; Wed, 26 Feb 2020 17:37:32 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:55844 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j75J4-0006W6-3H for lmi@nongnu.org; Wed, 26 Feb 2020 17:37:30 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j75J0-000248-Ky; Wed, 26 Feb 2020 23:37:26 +0100 Date: Wed, 26 Feb 2020 23:37:26 +0100 From: Vadim Zeitlin To: "Let me illustrate..." cc: Greg Chicares MIME-Version: 1.0 Content-Type: MULTIPART/SIGNED; protocol="application/pgp-signature"; micalg=pgp-sha1; BOUNDARY="446613808-41-1582756646=:7932" References: In-Reply-To: X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.240.17.225 Subject: Re: [lmi] Shell scripting bafflement X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 22:37:34 -0000 --446613808-41-1582756646=:7932 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE On Wed, 26 Feb 2020 22:27:11 +0000 Greg Chicares wrote: GC> Vadim--Sorry to bother you with this, but I just can't see why GC> these two nearly-identical commands behave oppositely, and I'm GC> sure you'll know why. I think I do, but I feel like I'm missing something crucial here: why do you say that these commands are nearly-identical when it looks to me that they're not identical at all? GC> This does exactly what I expect, as [non]gnu.org is certainly GC> reachable on my machine: GC> GC> /home/greg[0]$if curl https://git.savannah.nongnu.org:443 >/dev/null 2>&1 ; then GC> echo true GC> else GC> echo false GC> fi GC> GC> true This checks the exit code of curl command, which is 0 in this case, and so is considered to be "true". GC> But if I enclose the command in "[ $(...) ]", it "fails": This tests... nothing. $(...) expands to nothing because there is no output of curl, as you had taken care to suppress it, and so this is equivalent to "[ ]". To be honest, I didn't know what does testing nothing does, but it turns out that it always returns false. It can be seen by doing $ [ ] || echo false false or $ test || echo false false GC> /home/greg[0]$ GC> /home/greg[0]$if [ $(curl https://git.savannah.nongnu.org:443 >/dev/null 2>&1) ]; then GC> echo true GC> else GC> echo false GC> fi GC> GC> false So this doesn't seem surprising to me at all. But I can't figure out what was your intention here, i.e. _why_ do you use the command expansion shell construct and what exactly do you expect to obtain from it? Please let me know if I'm missing something obvious here, VZ --446613808-41-1582756646=:7932 Content-Type: APPLICATION/PGP-SIGNATURE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iEYEABECAAYFAl5W8yYACgkQBupB3k9sHoZDtACfTohqdxpFOKWslEGYxq8lyYdR PooAoKI7zIIAB/j8PWxRPDJa555inUKL =wpyz -----END PGP SIGNATURE----- --446613808-41-1582756646=:7932-- From MAILER-DAEMON Wed Feb 26 19:34:13 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j7781-0002Uc-2q for mharc-lmi@gnu.org; Wed, 26 Feb 2020 19:34:13 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53171) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j777y-0002UR-NQ for lmi@nongnu.org; Wed, 26 Feb 2020 19:34:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j777x-00068z-9j for lmi@nongnu.org; Wed, 26 Feb 2020 19:34:10 -0500 Received: from sonic312-25.consmr.mail.bf2.yahoo.com ([74.6.128.87]:33362) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j777x-00062i-1f for lmi@nongnu.org; Wed, 26 Feb 2020 19:34:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1582763647; bh=LhZed5qwUKvd5YZp5nnKBpWVj37FnyiV05p7/A37uh0=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=Hg6Ur9lv/H5qSMWLoQiOm04iQkDFv87bDnleTsdK3BchHk0wgWUEb8wotP8Q0pNuk6usrLj3llR3Vac5hj5H1G4ZnYUx0QGtRxkEVe9eX95w2xH0MJrUf7PQ+6F/U0iTUO09bSQp0MhS+NuXlXUF6tnusQbhVDfPIALWGXUd2zSJVwEBxxRs6Blujos4jVBrxQFgOjf9Jq322M25PmTMj5QPVReZxtEGj3EOv37Zwc9dwD1UAIRYxbe2AJYyT6DzKUbbFHLN0c+l4n2bwA24YY/1X+frXeZUE+F7iUHQAgKB6kGeONmaLHQvhzlKIWpshks4HPfB5UHYUniRdSnfIQ== X-YMail-OSG: OkmY964VM1mlHyJ9TB.5J8lw5T01281iGzig0DNRkdBHjhw4VUYNpcbTGlcYixl HQfBeuNad.ZAMoMIUsTfK2aMMjmP1Th5lsYRHbrgLWJLi8fMDVdqg_41YibsGlBBT022mW5p9yzq QTl2hgYipAEZQuxowkPCUrv2eFpHQGvebLcb9QVSXWtZkxUiIU6PPIRh6jEJ5xdnBoSBO3Bidaww vd8LYt1o1QcWCnCkiscFyfDrkq6k60bQ3aDCpfUqJTp9GVmdQTtjxLyWsEPtkjN6pqf8OOKM6TNU q1oJ1.Y0kBRnkAbt9XjWNp9Os_Bx93fXUxr0sB7bg_c5jpYnag4cnJkVgBd1WpWYKFXJoLLxvjij TtneofLR0ITI5JznfjHydkP0LVWNFV81axIERRMZpgpwzhoqUUtwhcYhHLpkNDljwtKnkiU6sJus DAtcmDXeDQwSvVf6cQVuxTAPMqWVpYrpWce0Wvs8603CmqkRLwITKlNkAAjV.0SSIqry4VgHCiGY .lcl6UWtlDzueKdW3jb0VTsKjhdcdCPCwv_ZazrWzOrcHfkrSP54QdyjMjU52cgVRiEDllXPIBpg XkjmfS0uxKHD6.etcNUtsyt6JF7MAFbYXveFQKiPf8GCd0a8KewQ.vgo4rEp9yImMfLeT78lrPpt lv2U7Z9JytzfpFyIPcL2jBKJmaW0ByDdlwG2fU1dkR8ZmfscNd.zEl28d4iGFUUzBimpNwBWwPpS jLzpRh0WNOa3A4xjsJvsFobS5HqOS4oBzndeozsPXLILrezSd0Sdl3xTF4mGEB7J6umReDASMwCn 5pb7Jvh0JnTbE6PuPJJPsVu4RNzEH5unVmTxK0MuDS20bryV4nVQQkSJM8OGAwWkc9uRLzEbjQgw fo4UXwD5Zt6qy2KXXm8pZPntGaPz5.2DEu.S6EzkXlR1A4MeiORIW9uiuwzp12D989yhoIwIy1f7 DN47rEpQ1OXbpy2Qq_eZLOhbryoGglrhRZgobOl3nEQ7rzvw9bExkrS7YDwB2POC5CIv339DfRux jNTmerjSSi4etrDi_s4OlA2Qw9Od4DbkGKjRG04GelsHyBouGd3t5k8BpSEtnZ_TkcgKrjHp1O1y .zUih9bsDIk.X6YQLmrAOcM4bnKy5PrO6JI6W0yhbJaTf.myw4EbpgahGM0iphg51vOe2COqP.yF hopjvkw9CcSQIPZ0oVMfEJRGtFl70DIcimalw.jrr7MPQY1aOkCpUZcmDdO7XGnt9mmo3Ux1CQ0. bfg7kxiTV8OzP4LLNV_JQb0PHsudNWJnMXXidYyMO6PnfzvDknZfkHiyUTefGkREGJEeDSS5ofPe gj6wnXBSyrwgAZJNYZ1jnhvKkqV5mHwdx19RreLXwF_c7MQJS.CfXkIg_hJUzXCwlzSuCmMo.Q_L NZOOmLtf.pJBuq2Ryk4IHZ6h.Nlw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Thu, 27 Feb 2020 00:34:07 +0000 Received: by smtp408.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7e4d32f8a5b05967194c6c949bb9e0e1; Thu, 27 Feb 2020 00:34:02 +0000 (UTC) To: "Let me illustrate..." References: From: Greg Chicares Message-ID: <42e27cb5-77b4-c662-d572-f584adfd2fdf@sbcglobal.net> Date: Thu, 27 Feb 2020 00:34:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.15302 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_241) Content-Length: 4114 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.128.87 Subject: Re: [lmi] Shell scripting bafflement X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 00:34:12 -0000 On 2020-02-26 22:37, Vadim Zeitlin wrote: > On Wed, 26 Feb 2020 22:27:11 +0000 Greg Chicares wrote: > > GC> Vadim--Sorry to bother you with this, but I just can't see why > GC> these two nearly-identical commands behave oppositely, and I'm > GC> sure you'll know why. > > I think I do, but I feel like I'm missing something crucial here: why do > you say that these commands are nearly-identical when it looks to me that > they're not identical at all? That's because you understand what they mean. To me, they're more like abstract strings of symbols. Evidently s/cmd/[ $(&) ]/ does make a difference in practice, yet I anticipated that $() and [] would be nilpotent--and, specifically, that I could take a valid conditional like if [ "$(id -u)" -eq 0 ]; then ... and replace everything within "[]" with some command to produce another valid conditional. But already I lead myself astray, because I think of that as similar to a C++ construct like if(true == some_boolean_function()) which is trivially the same as if(some_boolean_function()) yet the following two shell constructs are not the same: if [ "$(id -u)" -ne 0 ] ; then echo true; else echo false; fi if [ "$(id -u)" ] ; then echo true; else echo false; fi because the former prints "true" iff I am not root, but the latter prints "true" whether or not I am root. Let me try to explain that in light of what else you said... > GC> But if I enclose the command in "[ $(...) ]", it "fails": > > This tests... nothing. $(...) expands to nothing because there is no > output of curl, as you had taken care to suppress it, and so this is > equivalent to "[ ]". To be honest, I didn't know what does testing nothing > does, but it turns out that it always returns false. This: if [ ] ; then echo true; else echo false; fi always prints "false". So why did if [ $(id -u) ] ; then echo true; else echo false; fi always print "true", regardless of `whoami`? The explanation is that if I'd "taken care to suppress" the output: if [ $(id -u 2>&1 >/dev/null) ] ; then echo true; else echo false; fi then it would print "false" instead. Right? Here's my hypothesis: a shell command is like one of those classic C functions that returns something and also potentially sets errno: - the shell command's return code is like C's errno - the C return value is like the shell command's output Is that a helpful way of looking at it? > So this doesn't seem surprising to me at all. But I can't figure out what > was your intention here, i.e. _why_ do you use the command expansion shell > construct and what exactly do you expect to obtain from it? Tackling my problematic command if [ $(curl https://git.savannah.nongnu.org:443 >/dev/null 2>&1) ]; then from the inside out, I thought as follows. This is the command I want to run: curl https://git.savannah.nongnu.org:443 This throws away 27 lines of output that I don't want to see: curl https://git.savannah.nongnu.org:443 >/dev/null 2>&1 Now adding "$()": $(curl https://git.savannah.nongnu.org:443 >/dev/null 2>&1) means I only want the return code (0 if successful); so far, so good? No. I already had the return code, without "$()". Adding "$()" means: throw away the return code, and capture the text output--which would have been implicitly printed on the screen, except that I discarded it. Right? Well, maybe not. Consider the following commands, which - test a resolvable URL vs. one spoiled by adding 'X' after "https://" - with vs. without "$()" $if curl https://Xgit.savannah.nongnu.org:443 >/dev/null 2>&1; then echo true; else echo false; fi false $if curl https://git.savannah.nongnu.org:443 >/dev/null 2>&1; then echo true; else echo false; fi true $if $(curl https://Xgit.savannah.nongnu.org:443 >/dev/null 2>&1); then echo true; else echo false; fi false $if $(curl https://git.savannah.nongnu.org:443 >/dev/null 2>&1); then echo true; else echo false; fi true The effects seem to be the same with or without "$()", so what does the the "$()" do in this case? And why does it seem to make no difference? From MAILER-DAEMON Wed Feb 26 21:39:01 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j794n-0004jl-67 for mharc-lmi@gnu.org; Wed, 26 Feb 2020 21:39:01 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33283) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j794j-0004eT-Gh for lmi@nongnu.org; Wed, 26 Feb 2020 21:38:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j794e-0007vS-NN for lmi@nongnu.org; Wed, 26 Feb 2020 21:38:57 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:58178 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j794e-0007qr-Cu for lmi@nongnu.org; Wed, 26 Feb 2020 21:38:52 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j794a-00011m-JU; Thu, 27 Feb 2020 03:38:48 +0100 Date: Thu, 27 Feb 2020 03:38:48 +0100 From: Vadim Zeitlin To: "Let me illustrate..." cc: Greg Chicares MIME-Version: 1.0 Content-Type: MULTIPART/SIGNED; protocol="application/pgp-signature"; micalg=pgp-sha1; BOUNDARY="461095490-41-1582771128=:7932" References: <42e27cb5-77b4-c662-d572-f584adfd2fdf@sbcglobal.net> In-Reply-To: <42e27cb5-77b4-c662-d572-f584adfd2fdf@sbcglobal.net> X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.240.17.225 Subject: Re: [lmi] Shell scripting bafflement X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 02:38:59 -0000 --461095490-41-1582771128=:7932 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE On Thu, 27 Feb 2020 00:34:01 +0000 Greg Chicares wrote: GC> That's because you understand what they mean. To me, they're more like GC> abstract strings of symbols. Evidently GC> s/cmd/[ $(&) ]/ GC> does make a difference in practice, yet I anticipated that $() and [] would GC> be nilpotent--and, specifically, that I could take a valid conditional like GC> if [ "$(id -u)" -eq 0 ]; then ... GC> and replace everything within "[]" with some command to produce another GC> valid conditional. I think an important thing to understand here is that originally "[]" had no special meaning whatsoever. In fact, "[" was, and still remains, just a command with (very) weird name. You can try running "where [" (from zsh) or "ls -l /usr/bin/\[" to check this. Nowadays shells do have special "[[ ... ]]" syntax which, for many good reasons, should be preferred to "[]", but the latter still works and its history explains some of its quirks. And, of course, dash doesn't support "[[", so we're limited to "[" if you want to support any kind of /bin/sh, including dash. BTW, you might know "[" under its alternative name, which is "test". On my system they're different commands but I'm pretty sure that historically one of them could be, and was, just a symlink to the other one, although I don't remember in which sense it went any longer. GC> > GC> But if I enclose the command in "[ $(...) ]", it "fails": GC> > GC> > This tests... nothing. $(...) expands to nothing because there is no GC> > output of curl, as you had taken care to suppress it, and so this is GC> > equivalent to "[ ]". To be honest, I didn't know what does testing nothing GC> > does, but it turns out that it always returns false. GC> GC> This: GC> if [ ] ; then echo true; else echo false; fi GC> always prints "false". So why did GC> if [ $(id -u) ] ; then echo true; else echo false; fi GC> always print "true", regardless of `whoami`? The explanation is GC> that if I'd "taken care to suppress" the output: GC> if [ $(id -u 2>&1 >/dev/null) ] ; then echo true; else echo false; fi GC> then it would print "false" instead. Right? Yes. Also, the version without output suppressing prints true, regardless of your user ID, because "[ N ]" returns true for any number N, even if this number is 0. However just "[ ]" returns false (which is something I had never run into until today, so I guess it's not that widely known). GC> Here's my hypothesis: a shell command is like one of those classic C GC> functions that returns something and also potentially sets errno: GC> - the shell command's return code is like C's errno GC> - the C return value is like the shell command's output GC> Is that a helpful way of looking at it? I don't know really know if it's helpful, but it's more or less exact. And "errno" is called "exit code", or "$?". GC> > So this doesn't seem surprising to me at all. But I can't figure out what GC> > was your intention here, i.e. why do you use the command expansion shell GC> > construct and what exactly do you expect to obtain from it? GC> GC> Tackling my problematic command GC> if [ $(curl https://git.savannah.nongnu.org:443 >/dev/null 2>&1) ]; then GC> from the inside out, I thought as follows. This is the command I want to run: GC> curl https://git.savannah.nongnu.org:443 GC> This throws away 27 lines of output that I don't want to see: GC> curl https://git.savannah.nongnu.org:443 >/dev/null 2>&1 GC> GC> Now adding "$()": GC> $(curl https://git.savannah.nongnu.org:443 >/dev/null 2>&1) GC> means I only want the return code (0 if successful); so far, so good? GC> No. I already had the return code, without "$()". Adding "$()" means: GC> throw away the return code, and capture the text output--which would GC> have been implicitly printed on the screen, except that I discarded it. GC> Right? Yes. GC> Well, maybe not. Consider the following commands, which GC> - test a resolvable URL vs. one spoiled by adding 'X' after "https://" GC> - with vs. without "$()" GC> GC> $if curl https://Xgit.savannah.nongnu.org:443 >/dev/null 2>&1; then echo true; else echo false; fi GC> false GC> $if curl https://git.savannah.nongnu.org:443 >/dev/null 2>&1; then echo true; else echo false; fi GC> true GC> GC> $if $(curl https://Xgit.savannah.nongnu.org:443 >/dev/null 2>&1); then echo true; else echo false; fi GC> false GC> $if $(curl https://git.savannah.nongnu.org:443 >/dev/null 2>&1); then echo true; else echo false; fi GC> true GC> GC> The effects seem to be the same with or without "$()", so what does the GC> the "$()" do in this case? And why does it seem to make no difference? The difference is that you don't use "[" at all here. What happens with "if" is that you only test "$?" because this is what "if" does. However with "[]" you pass it the string containing the test and it doesn't care at all about the state of "$?" at the moment when this string was generated. "[", or "test", sets "$?" itself as the result of interpreting its arguments using its own syntax (see test(1)). What can I say, nobody ever pretended shell wasn't confusing. IMHO this is not the worst part, because typically once you realize the difference between "if command" and "if test condition", things should be relatively clear. The best advice I can give about shell scripting is to always test anything you might have a doubt about in a separate snippet to ensure that it behaves as you expect it to, because failures in the actual scripts are hard to debug and often lead to unforeseeable weirdness later on. Good luck, VZ --461095490-41-1582771128=:7932 Content-Type: APPLICATION/PGP-SIGNATURE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iEYEABECAAYFAl5XK7gACgkQBupB3k9sHoaenwCdGk5z84Pdx7QTIuomf7/s2p40 +B0An3GW+QQHC/DYywg01FwX7baGVUZZ =UrcM -----END PGP SIGNATURE----- --461095490-41-1582771128=:7932-- From MAILER-DAEMON Thu Feb 27 18:14:09 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j7SM5-0001Ts-JV for mharc-lmi@gnu.org; Thu, 27 Feb 2020 18:14:09 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58514) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j7SM3-0001Tj-A5 for lmi@nongnu.org; Thu, 27 Feb 2020 18:14:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j7SM2-0001rI-2S for lmi@nongnu.org; Thu, 27 Feb 2020 18:14:07 -0500 Received: from sonic311-20.consmr.mail.bf2.yahoo.com ([74.6.131.194]:37410) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j7SM1-0001qi-Pq for lmi@nongnu.org; Thu, 27 Feb 2020 18:14:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1582845242; bh=y/HLoCxgMjXjp30yNabJQNXP2TbiLOqVACVKNeawPT4=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=ECNw2L7ZNOV2lvhq0jf0YH+A5XPKgb7dwz69dogajFWi7QkCVwx3QXM9yUTfQbIW3F7ewpdpfn0ezIiYourWHkSZpPJEFBHtoQY+kB2+HLOL9qjb8y1FXJSL/ARW+4xRD+DWSIJKgW0yKWn60vkSxPw+myhaYMXOqrP+TctdMZakg1jNYQzcLmArRC1tuWS7ymUsqGSgIuyZwxZxLrRqMjIJPnLDEe9FCtU1m5Cvjm7YgtFUVuOGrke8ymv5yFJZCMoTCMrKi6KrCNw8m78/lxl7KjcvL6NTjqTXDz384VN1ylfYRpi7ZRIEKGAGmMwB+sMWXTG1HE6O1QS3GusgVw== X-YMail-OSG: nMKZd_YVM1lyppWweX1Ox3N7VTPAsrzRi0ChwG6MnEY1gTa6S6g6y4a5aUpnFL3 DhOnragtrBQI48Q4Lppscs0Q3FE.dkJTi.zNOufBrazC8xSCdJYvu6ZGozvuamK8OthH9ENj091D sb66qn3Jz4UKLQxaGkuDIcwQKfK7X_DPzy65r9xnBCtY90uwOSvfGBfDvsAu59OaR8a32zb9mDxo 79Cy.jQGLZiqrlddAng.xnNLDIz8y4xuvRveqsM7.O2fR619T.7Aoe8aznPvPa5rdw4uI9e77Xo2 R55aMnLjx09GJ0h.Bf044fS.av_9APbhWzdLSV2n79Qvr.cmHCMb2iMYafT2R8Q7x.IJifUsuUEF NqgnHpbF4oM3A2gxZBv2_3ul9FoZMUpVktTNfwTQDm605fKCqkOYfqX8XeA.8dwdje5oBg0ARCZy f8dBQNPU6IjVo4CVrBSwZXO_RO38A0wx6o7.7LydTSsQELgcy4pp2eD72nl7_z7KuPTclQdu0.8T ZLHNPQnOFcBtYRqauLWljyV_xQ2mOLfMRsSEsP9F1LUvefxOa4PJs348RD_OpGnfvFf2P8ylazUP DLMMmwaibkloj3jfGMv.nEk4G_3hq4Fj4x34_MjODHk3ukpBSlYzpSbW4Wt5E3F1REcBBKDFT4lV JTXEeYL73V8isDznpHNCW9ioh_5h_N3IfpAN87zlN9yGcf0Fd9wR9cDqgXzr_Msu79ZejMS3F5Kx LIBuzceehnR7j_O81v234vVMt2uMwMTFXXrQG0xPtzNtg85PUE2kMlImztP9uya.YF2s9afbRDXd uVrvDm07pabQk_dfMA2xD4iApexWgsyzhBZ5OkxbfkVVbMP09waFRV02aCnXhiK0WG976BX_ii.G VWem7H5nX.4N5n5Nw0E9EMNkTn5Nx3x__gDOy84L4xYLT3XpmDLjx3nSx.Beu5r19.l2saY9cF1f BakRbXtzSN0plZiQCTKBDufWPVXvRlRItx1LDdAYFPlpwqpTtuWCePE6_omtjfTXyyxtO3_O.mxc cRMVgCnm3205Ke_F7Mgdp7vJwwGKkiC6Y_9ybb.5Qt1gJQtz5jtNwViW3L6BCT7VthYS4VYUZaz3 01XtqY.hPgT5Ues3qv5aWzk5iP7ovUouQBJjbgI.4VAktGw3WrTbAPtahz5Ih_.OvPsf3uAXrlpF Fqi_j0FGsEc2KyAbL8Un8ayJPEIsYcl0Fm4VmvWZWnVUOxtOlFw5A497ALR1o.k12m9b_HQMepw_ sW32WPSO1MmWyzcMwdqpJMxAtqqyA4Abnu2Lsk1DKkW7JQxZKARm7d79J8BgCrJknhEutVX0H9wn p7RhtsIZ3UhaALlxyJd5LHYHUmW9YJ6jvwv5J7OQayAqvoZhsCkg6.i37DGAkR74rC7.1QLT1e77 SqQAFOxqgghv6AA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Thu, 27 Feb 2020 23:14:02 +0000 Received: by smtp407.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID fb850222dd4212f367484baa16b1270d; Thu, 27 Feb 2020 23:13:59 +0000 (UTC) To: "Let me illustrate..." References: <42e27cb5-77b4-c662-d572-f584adfd2fdf@sbcglobal.net> From: Greg Chicares Message-ID: <046dceba-2b1a-d4a7-41b2-8f5564819996@sbcglobal.net> Date: Thu, 27 Feb 2020 23:13:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.15302 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_241) Content-Length: 3142 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.6.131.194 Subject: Re: [lmi] Shell scripting bafflement X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 23:14:08 -0000 On 2020-02-27 02:38, Vadim Zeitlin wrote: > On Thu, 27 Feb 2020 00:34:01 +0000 Greg Chicares wrote: [...] > GC> Consider the following commands, which > GC> - test a resolvable URL vs. one spoiled by adding 'X' after "https://" > GC> - with vs. without "$()" > GC> > GC> $if curl https://Xgit.savannah.nongnu.org:443 >/dev/null 2>&1; then echo true; else echo false; fi > GC> false > GC> $if curl https://git.savannah.nongnu.org:443 >/dev/null 2>&1; then echo true; else echo false; fi > GC> true > GC> > GC> $if $(curl https://Xgit.savannah.nongnu.org:443 >/dev/null 2>&1); then echo true; else echo false; fi > GC> false > GC> $if $(curl https://git.savannah.nongnu.org:443 >/dev/null 2>&1); then echo true; else echo false; fi > GC> true > GC> > GC> The effects seem to be the same with or without "$()", so what does the > GC> the "$()" do in this case? And why does it seem to make no difference? > > The difference is that you don't use "[" at all here. Okay, yes, that explains the difference between if [ command ] and if [ $(command) ] , but I'd like to ask a different question: what's the difference between if $(curl some_URL >/dev/null 2>&1) and if curl some_URL >/dev/null 2>&1 ? In the examples quoted above, they appear to behave identically. I found that surprising. I understand that in if curl some_URL >/dev/null 2>&1 the command's return code is 0 or not depending on the URL's reachability. However, here: if $(curl some_URL >/dev/null 2>&1) I was expecting that - the command would be run in a subshell - the command's return code would vanish when that subshell returns - the command-expansion's return code would be 0 if the subshell executed the command but it seems that the command-expansion's return code is the command's return code. The bash manual prescribes that: https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Simple-Command-Expansion | If one of the expansions contained a command substitution, the | exit status of the command is the exit status of the last | command substitution performed. but AFAICT POSIX doesn't specify anything: https://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03 > What can I say, nobody ever pretended shell wasn't confusing. IMHO this is > not the worst part, because typically once you realize the difference > between "if command" and "if test condition", things should be relatively > clear. Yeah. Some languages were designed, and show a coherent set of design principles. OTOH, other languages (e.g., the shell grammar) have evolved, like a natural human language. > The best advice I can give about shell scripting is to always test > anything you might have a doubt about in a separate snippet to ensure that > it behaves as you expect it to, because failures in the actual scripts are > hard to debug and often lead to unforeseeable weirdness later on. That's how I came up with this test: if [ "$(umask)" -ne 022 ]; then in lmi commit 135b344eb6d. I always have to look up the syntax for comparisons like that. (Using 'shellcheck' helps, too.) From MAILER-DAEMON Thu Feb 27 18:52:18 2020 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1j7Sx0-0000Y7-L7 for mharc-lmi@gnu.org; Thu, 27 Feb 2020 18:52:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35701) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j7Swx-0000Xr-1j for lmi@nongnu.org; Thu, 27 Feb 2020 18:52:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j7Swv-00083X-By for lmi@nongnu.org; Thu, 27 Feb 2020 18:52:14 -0500 Received: from sunset.tt-solutions.com ([82.240.17.225]:42400 helo=smtp.tt-solutions.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j7Swv-00082u-3o for lmi@nongnu.org; Thu, 27 Feb 2020 18:52:13 -0500 Received: from [192.168.17.86] (helo=Twilight.zeitlins.org) by smtp.tt-solutions.com with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j7Swr-0006C7-PB; Fri, 28 Feb 2020 00:52:09 +0100 Date: Fri, 28 Feb 2020 00:52:09 +0100 From: Vadim Zeitlin To: "Let me illustrate..." cc: Greg Chicares MIME-Version: 1.0 Content-Type: MULTIPART/SIGNED; protocol="application/pgp-signature"; micalg=pgp-sha1; BOUNDARY="537492883-41-1582847529=:7932" References: <42e27cb5-77b4-c662-d572-f584adfd2fdf@sbcglobal.net> <046dceba-2b1a-d4a7-41b2-8f5564819996@sbcglobal.net> In-Reply-To: <046dceba-2b1a-d4a7-41b2-8f5564819996@sbcglobal.net> X-Mailer: Mahogany 0.68.0 'Cynthia', running under Windows 7 (build 7601, Service Pack 1), 64-bit edition Message-Id: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.240.17.225 Subject: Re: [lmi] Shell scripting bafflement X-BeenThere: lmi@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Let me illustrate..." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 23:52:16 -0000 --537492883-41-1582847529=:7932 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE On Thu, 27 Feb 2020 23:13:58 +0000 Greg Chicares wrote: GC> , but I'd like to ask a different question: what's the difference between GC> if $(curl some_URL >/dev/null 2>&1) GC> and GC> if curl some_URL >/dev/null 2>&1 GC> ? Well, to be honest, the main difference is that the latter is perfectly normal and expected while the former is something weird I had never seen before the start of the thread. Shell has a lot of dark corners (could it be a distant relative of Shelob?) and I frankly don't think it's worth or safe for one's sanity to try to deal with them. My advice would be to just avoid them instead. GC> In the examples quoted above, they appear to behave identically. I found GC> that surprising. I understand that in GC> if curl some_URL >/dev/null 2>&1 GC> the command's return code is 0 or not depending on the URL's reachability. GC> However, here: GC> if $(curl some_URL >/dev/null 2>&1) GC> I was expecting that GC> - the command would be run in a subshell GC> - the command's return code would vanish when that subshell returns From my point of view, this seems like a strange expectation because normally the shell exits with the exit code of the command which ran in it: % /bin/sh -c 'exit 123' || echo $? 123 % /bin/sh -c /bin/false || echo $? 1 % /bin/sh -c /bin/true || echo $? % # nothing printed above, as expected GC> - the command-expansion's return code would be 0 if the subshell GC> executed the command GC> but it seems that the command-expansion's return code is the GC> command's return code. Yes, and this seems right and proper to me. GC> The bash manual prescribes that: GC> GC> https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Simple-Command-Expansion GC> | If one of the expansions contained a command substitution, the GC> | exit status of the command is the exit status of the last GC> | command substitution performed. GC> GC> but AFAICT POSIX doesn't specify anything: GC> https://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03 I can't indeed find anything about this in POSIX, but the fact that Dash behaves like this makes me think that it might be still specified somewhere because this shell authors would certainly have chosen a simpler way (and not preserving the exit code is simpler than preserving it) if it were legal from POSIX point of view as they seem to positively enjoy striving for minimalism for its own sake. GC> > What can I say, nobody ever pretended shell wasn't confusing. IMHO this is GC> > not the worst part, because typically once you realize the difference GC> > between "if command" and "if test condition", things should be relatively GC> > clear. GC> GC> Yeah. Some languages were designed, and show a coherent set of design GC> principles. OTOH, other languages (e.g., the shell grammar) have evolved, GC> like a natural human language. From this point of view, it feels weird for an atheist like me to like Perl family languages that are the best example of intelligent design I can think of... But shell is too chaotic-evil even for me. Regards, VZ --537492883-41-1582847529=:7932 Content-Type: APPLICATION/PGP-SIGNATURE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iEYEABECAAYFAl5YVikACgkQBupB3k9sHoaJBgCgjrLxZowKTkOdpORQFVjsfJgc SJ0AoJni3XWkSd2CiNfSKPbwP/ctt2oQ =NgVw -----END PGP SIGNATURE----- --537492883-41-1582847529=:7932--