Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
On 01/04/2012 10:24 PM, Axel Beckert wrote: Hi Simon, Simon McVittie wrote: On Mon, 02 Jan 2012 at 16:26:55 -0500, Yaroslav Halchenko wrote: On Mon, 02 Jan 2012, Axel Beckert wrote: /tmp is a good choice because the next reboot will automatically clean up everything (and obviously the old binary will not be needed after a reboot). Thank you Axel for your detailed response and IMHO this is indeed close to an ideal (lightweight, self-cleaning, etc) resolution for this scenario. BTW -- what is the take of standards/practices on having /tmp mounted with noexec [1]? Would it be enough for the your old screen binary is /tmp/screen-yhpoe8r/screen notice to also say if your /tmp is mounted noexec, you might need to copy it elsewhere to run it? That's my current plan -- with the noexec notice just being displayed if /tmp actually is mounted noexec. Good plan, but I'd also vouch for few lines in the release notes, still. Even you are planning on doing it with debconf, which after all, is the only thing we should do (just echoing on the console is bad). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f0c1a53.7070...@debian.org
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Hi Tollef, Tollef Fog Heen wrote: Not really a serious suggestion, but for completeness E) ignore the problem and just let people rescue the programs stuck in the old screen using retty, reptyr or similar. My experiences with one of these tools (IIRC retty, but I'm not sure) a few years ago were not very successful so I did not take this option into account. Haven't tried any other tools since then. Additionally, rescueing apt or aptitude if the according tool is not yet installed is likely impossible without killing the running apt/aptitude to install that tool. But yeah, if we have options which are not much work, but assist the admins in the dist-upgrade a lot, all less comfortable or rough options, like this, can be ignored. Thanks for the comment anyway. I learned that there is more than one tool which could fetch a running program into screen. :-) Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120104095959.ge20...@sym.noone.org
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
On Tue, Jan 03, 2012 at 04:04:04PM +0100, Axel Beckert wrote: Hi, Roger Leigh wrote: [/tmp mounted noexec] /run/shm (IIRC formerly /dev/shm) likely would be an alternative option, too. No, it would not. This directory is reserved for the eglibc POSIX SHM/SEM interfaces. Thanks for this explanation. It's the first time I read or hear about the purpose of this mountpoint although I wondered about its purpose for years now. (But never actively tried to find out. :-) shm_overview(7) has some background. It's not obvious it's in use because most users unlink their file as soon as it's created, giving the false impression it's empty! Bastian Blank wrote: On Tue, Jan 03, 2012 at 10:05:46AM +, Roger Leigh wrote: If you really need to use a filesystem mounted noexec, just run the binary via /lib/ld.so (you'll need to get the real location from e.g. ldd). Something like: The kernel does not allow executable mappings from noexec filesystems, so this does not work. | $ /lib64/ld-linux-x86-64.so.2 ./ls | ./ls: error while loading shared libraries: ./ls: failed to map segment from shared object: Operation not permitted Thanks for the comment. Cc'ing the relevant bug again, as this is crucial information when I work on fixing the bug. Roger Leigh wrote: Or query for DT_INTERP directly and run that. Never heard of that before. Searching the web just found hits indicating it seems part of the ELF header. No idea how to work with it, though. Any hints? objdump would probably be the tool of choice. But if ld.so won't run programs on noexec filesystems, it's moot. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120104112103.gc18...@codelibre.net
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
On Mon, 02 Jan 2012 at 16:26:55 -0500, Yaroslav Halchenko wrote: On Mon, 02 Jan 2012, Axel Beckert wrote: /tmp is a good choice because the next reboot will automatically clean up everything (and obviously the old binary will not be needed after a reboot). Thank you Axel for your detailed response and IMHO this is indeed close to an ideal (lightweight, self-cleaning, etc) resolution for this scenario. BTW -- what is the take of standards/practices on having /tmp mounted with noexec [1]? Would it be enough for the your old screen binary is /tmp/screen-yhpoe8r/screen notice to also say if your /tmp is mounted noexec, you might need to copy it elsewhere to run it? Or you could just assume that any sysadmin who has deliberately enabled noexec (not the default, after all) is able to realise (and deal with) the consequences :-) S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120104140428.gz22...@reptile.pseudorandom.co.uk
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Hi Simon, Simon McVittie wrote: On Mon, 02 Jan 2012 at 16:26:55 -0500, Yaroslav Halchenko wrote: On Mon, 02 Jan 2012, Axel Beckert wrote: /tmp is a good choice because the next reboot will automatically clean up everything (and obviously the old binary will not be needed after a reboot). Thank you Axel for your detailed response and IMHO this is indeed close to an ideal (lightweight, self-cleaning, etc) resolution for this scenario. BTW -- what is the take of standards/practices on having /tmp mounted with noexec [1]? Would it be enough for the your old screen binary is /tmp/screen-yhpoe8r/screen notice to also say if your /tmp is mounted noexec, you might need to copy it elsewhere to run it? That's my current plan -- with the noexec notice just being displayed if /tmp actually is mounted noexec. Or you could just assume that any sysadmin who has deliberately enabled noexec (not the default, after all) is able to realise (and deal with) the consequences :-) As I wrote in another mail, you once enable this and forget about it then, after years, wonder, why some upgraded software suddenly behaves strangely. BTDT. :-) So I think it's more admin friendly to write a nice reminder. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120104142406.gh20...@sym.noone.org
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Axel Beckert a...@debian.org wrote: Simon McVittie wrote: Would it be enough for the your old screen binary is /tmp/screen-yhpoe8r/screen notice to also say if your /tmp is mounted noexec, you might need to copy it elsewhere to run it? That's my current plan -- with the noexec notice just being displayed if /tmp actually is mounted noexec. Will you need something similar if /tmp is mounted nosuid? I think that's more common. -M- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120104200537.ga7...@golux.woodcraft.me.uk
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
On Tue, Jan 03, 2012 at 07:17:04AM +0100, Axel Beckert wrote: Hi Yaroslav! Yaroslav Halchenko wrote: I strongly recommend this solution, along with a proper debconf notice. [...] /tmp is a good choice because the next reboot will automatically clean up everything (and obviously the old binary will not be needed after a reboot). Thanks for that hint. This sounds better (and especially less messy) than I thought! :-) Thank you Axel for your detailed response and IMHO this is indeed close to an ideal (lightweight, self-cleaning, etc) resolution for this scenario. BTW -- what is the take of standards/practices on having /tmp mounted with noexec [1]? Good point! /run/shm (IIRC formerly /dev/shm) likely would be an alternative option, too. No, it would not. This directory is reserved for the eglibc POSIX SHM/SEM interfaces. Please don't abuse it--we only just moved all the existing abusers to /run! Nothing other than eglibc has any business creating files there, ever. If you really need to use a filesystem mounted noexec, just run the binary via /lib/ld.so (you'll need to get the real location from e.g. ldd). Something like: LD=$(ldd /tmp/path/to/screen | grep ld-${arch} | sed -e 's/[[:space:]]*\(\/[^[:space:]]*\)[[:space:]].*/\1/') $LD /tmp/screen-94skls/screen Or query for DT_INTERP directly and run that. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120103100546.gy5...@codelibre.net
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
On Tue, Jan 03, 2012 at 10:05:46AM +, Roger Leigh wrote: If you really need to use a filesystem mounted noexec, just run the binary via /lib/ld.so (you'll need to get the real location from e.g. ldd). Something like: The kernel does not allow executable mappings from noexec filesystems, so this does not work. | $ /lib64/ld-linux-x86-64.so.2 ./ls | ./ls: error while loading shared libraries: ./ls: failed to map segment from shared object: Operation not permitted Bastian -- Our missions are peaceful -- not for conquest. When we do battle, it is only because we have no choice. -- Kirk, The Squire of Gothos, stardate 2124.5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120103104800.ga3...@wavehammer.waldi.eu.org
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
just thought of it: another possible complication of this approach (mv /usr/bin/screen /tmp/screen-4.0) might be -- tools depending on screen (e.g. byobu) might be in the cold water if the default screen in the PATH cannot do its duties. FWIW: $ apt-cache rdepends screen screen Reverse Depends: apt-dater winpdb surfraw-extra surfraw screenie |rtorrent podracer narval-utils mdm iselect epoptes-client education-common cereal byobu apt-dater /tmp is a good choice because the next reboot will automatically clean up everything (and obviously the old binary will not be needed after a reboot). Thanks for that hint. This sounds better (and especially less messy) than I thought! :-) -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120103135554.gd17...@onerussian.com
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
On Jan 03, Yaroslav Halchenko deb...@onerussian.com wrote: just thought of it: another possible complication of this approach (mv /usr/bin/screen /tmp/screen-4.0) might be -- tools depending on screen (e.g. byobu) might be in the cold water if the default screen in the PATH cannot do its duties. It does not matter, this is needed strictly for the time of the upgrade process. Stop overengineering. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Hi, Roger Leigh wrote: [/tmp mounted noexec] /run/shm (IIRC formerly /dev/shm) likely would be an alternative option, too. No, it would not. This directory is reserved for the eglibc POSIX SHM/SEM interfaces. Thanks for this explanation. It's the first time I read or hear about the purpose of this mountpoint although I wondered about its purpose for years now. (But never actively tried to find out. :-) Bastian Blank wrote: On Tue, Jan 03, 2012 at 10:05:46AM +, Roger Leigh wrote: If you really need to use a filesystem mounted noexec, just run the binary via /lib/ld.so (you'll need to get the real location from e.g. ldd). Something like: The kernel does not allow executable mappings from noexec filesystems, so this does not work. | $ /lib64/ld-linux-x86-64.so.2 ./ls | ./ls: error while loading shared libraries: ./ls: failed to map segment from shared object: Operation not permitted Thanks for the comment. Cc'ing the relevant bug again, as this is crucial information when I work on fixing the bug. Roger Leigh wrote: Or query for DT_INTERP directly and run that. Never heard of that before. Searching the web just found hits indicating it seems part of the ELF header. No idea how to work with it, though. Any hints? Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120103150404.gx20...@sym.noone.org
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
On Tue, 3 Jan 2012, Marco d'Itri wrote: It does not matter, this is needed strictly for the time of the upgrade process. Just how short do you expect this to be? I'm sure many of us dist-upgrade daily and (shock! horror!) don't reboot after each upgrade. We also don't expect existing processes to break or become inaccessible after an upgrade. I mean, I'll probably cope, but it's not quite the smooth, seamless experience that I generally expect. -- Edward Allcutt Who doesn't expect to reboot unless the kernel has changed. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1201031538580.20...@pandora.retrosnub.co.uk
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
On Jan 03, Axel Beckert a...@debian.org wrote: Thanks for the comment. Cc'ing the relevant bug again, as this is crucial information when I work on fixing the bug. If /tmp is noexec then the administrator mounted it this way and knows about it. So if he is smart enought to mount /tmp noexec then he can probably understand that he needs to copy the old binary somewhere else if and when it will be needed. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
On Jan 03, Edward Allcutt edw...@allcutt.me.uk wrote: On Tue, 3 Jan 2012, Marco d'Itri wrote: It does not matter, this is needed strictly for the time of the upgrade process. Just how short do you expect this to be? I'm sure many of us dist-upgrade daily and (shock! horror!) don't reboot after each upgrade. This is only relevant for stable to stable upgrades, if you use testing or unstable then you are supposed to be able to cope with such things. We also don't expect existing processes to break or become inaccessible after an upgrade. This is why you will get a debconf notice which will inform you about the needed workaround if you want to continue the upgrade and do not reboot soon after it. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Hi, Marco d'Itri wrote: If /tmp is noexec then the administrator mounted it this way and knows about it. Yeah, but that is possibly such a long time ago that it's not the first thought. So a small hint to fresh up the memory can't be bad. So if he is smart enought to mount /tmp noexec then he can probably understand that he needs to copy the old binary somewhere else if and when it will be needed. Yeah, and mentioning exactly this in the debconf notice makes it user friendly, too. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120103155808.gz20...@sym.noone.org
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Le mardi, 3 janvier 2012 16.58:08, Axel Beckert a écrit : Hi, Marco d'Itri wrote: If /tmp is noexec then the administrator mounted it this way and knows about it. Another idea would be to use /usr/bin as temporary place for the old screen. That would be a Policy violation but not a much bigger than using /tmp . 1) in screen/wheezy's `preinst upgrade`: cp /usr/bin/screen /usr/bin/screen-old touch /tmp/flag-screen-has-been-upgraded-no-reboot-yet (+ appropriate mktemp and usual version and sanity checks) 2) This means that as long as the machine hasn't been rebooted (/tmp emptied), both the new /usr/bin/screen and the old /usr/bin/screen-old exist for the admin to use. 3) In a screen-cleanup init script, test the inexistance of the flag and the existance of /usr/bin/screen-old; in that case, `rm` it. (+ appropriate version and sanity checks, + idempotency) This is mostly the put it under /tmp idea minus the noexec caveat, plus the init script insanity (which can be dropped in unstable as soon as Wheezy is released). Opinions ? OdyX signature.asc Description: This is a digitally signed message part.
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
On Jan 03, Didier Raboud o...@debian.org wrote: 3) In a screen-cleanup init script, test the inexistance of the flag and the existance of /usr/bin/screen-old; in that case, `rm` it. (+ appropriate version and sanity checks, + idempotency) This is bad, because to solve a possible 30 minutes issue you add an init script which slows down the boot process of every user for the whole life of the release. Do not overengineer. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Yaroslav Halchenko deb...@onerussian.com writes: Thank you Axel for your detailed response and IMHO this is indeed close to an ideal (lightweight, self-cleaning, etc) resolution for this scenario. Of course the real lightweight, self-cleaning solution is to not do anything special as the old binary will be kept by the kernel as /proc/serverpid/exe and can be used to reattach as long as the server is running. But I guess that for the sake of non-Linux users, keeping a copy in /tmp is more reasonable... -- Romain Francoise rfranco...@debian.org http://people.debian.org/~rfrancoise/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zke4wxhr@silenus.orebokech.com
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Hi, Romain Francoise wrote: Thank you Axel for your detailed response and IMHO this is indeed close to an ideal (lightweight, self-cleaning, etc) resolution for this scenario. Of course the real lightweight, self-cleaning solution is to not do anything special as the old binary will be kept by the kernel as /proc/serverpid/exe and can be used to reattach as long as the server is running. Yes and no. First, this seems to be just some (kind of) symbolic link: lrwxrwxrwx 1 root root 0 Jan 3 17:49 /proc/32039/exe - /usr/bin/screen (deleted) And I can't really execute it, neither as the user owning the screen session nor as root: ~ # /proc/32039/exe -ls zsh: permission denied: /proc/32039/exe Not sure if that's because of this fake symlink or due to other reasons, though. But I guess that for the sake of non-Linux users, keeping a copy in /tmp is more reasonable... That, too. Nevertheless, it would have been a tempting solution. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120103165504.ga20...@sym.noone.org
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Axel Beckert a...@debian.org writes: And I can't really execute it, neither as the user owning the screen session nor as root: ~ # /proc/32039/exe -ls zsh: permission denied: /proc/32039/exe Yes, /proc is mounted noexec so you need to use the ld-linux.so trick. But now that I actually try it, I realize that it makes screen lose its setgid bit, so it doesn't actually work in this context: root@silenus:~# screen -ls There is a screen on: 12255.pts-17.silenus(01/03/2012 07:44:49 PM)(Detached) 1 Socket in /var/run/screen/S-root. root@silenus:~# rm /usr/bin/screen root@silenus:~# file -L /proc/12255/exe /proc/12255/exe: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, BuildID[sha1]=0xc95e778d3362448aa7bfe3191f007d225652dc0a, stripped root@silenus:~# /proc/12255/exe -ls -su: /proc/12255/exe: Permission denied root@silenus:~# /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /proc/12255/exe -ls Directory '/var/run/screen' must have mode 777. root@silenus:~# Sorry for the false alarm. :) -- Romain Francoise rfranco...@debian.org http://people.debian.org/~rfrancoise/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lipowr42@silenus.orebokech.com
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
On Mon, 02 Jan 2012, Karl Goetz wrote: to fix a tiny problem which presents itself just for the length of the upgrade process, if at all. Correct. It's an option nevertheless, so I mentioned it. Sorry if I've misunderstood, but doesn't this problem manifest for *anyone* trying to ssh from a wheezy system to a squeeze system? Only if you're tunelling the screen protocol itself over ssh, which is not how it is normally used. In fact, I am not even sure you can do it that way... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120102114033.ga27...@khazad-dum.debian.net
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Hi, Romain Francoise wrote: 3) Tell people via the release notes that they should not run the dist-upgrade inside screen, but inside tmux instead. Unfortunately tmux has an issue of its own for squeeze → wheezy upgrades, .oO( Houston, we've got a problem. ) the socket path was changed from /var/run/tmux to /tmp in order to remove the setgid bit from the binary. So while the protocol itself hasn't changed, the new tmux won't see the old servers unless given the path explicitly (as documented in NEWS.Debian). Ok, but that either involves some more commandline options or some symbolic link(s) and is therefore do-able for every better admin (i.e. those who read documentation). *phew* :-) Thanks for the information! Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120102130147.go20...@sym.noone.org
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Hi Julien, Julien Cristau wrote: A) Add an option to screen so the screen client speaks the old protocol to the running server protocol. This IMHO would be best solution and one without a big impact. It's also something which could be Debian-only, i.e. a patch. (It of course would be better if upstream could be convinced to add such an option. :-) Why would that need an option? Can't the protocol version be discovered on connection? Good point. I suspect that the current code doesn't do that: screen 4.1.0 IIRC just hangs when it tries to speak with a 4.0.3 server. I suspect that this part is not yet so sophisticated since it's (according to the commit message) the first time they ever bumped the protocol version. The two processes seem to tell each other which protocol version they speak and then don't care about it anymore. :-/ Of course, auto-detection would be perfect (if implemented by upstream), but I suspect that as scope for a Debian-specific patch the command-line option would be easier to implement. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120102184703.gs20...@sym.noone.org
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
On Mon, 02 Jan 2012, Axel Beckert wrote: I strongly recommend this solution, along with a proper debconf notice. [...] /tmp is a good choice because the next reboot will automatically clean up everything (and obviously the old binary will not be needed after a reboot). Thanks for that hint. This sounds better (and especially less messy) than I thought! :-) Thank you Axel for your detailed response and IMHO this is indeed close to an ideal (lightweight, self-cleaning, etc) resolution for this scenario. BTW -- what is the take of standards/practices on having /tmp mounted with noexec [1]? I just wondered if that might be worth a check/warning during moving the binary [1] http://serverfault.com/questions/72356/how-useful-is-mounting-tmp-noexec -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120102212655.gc17...@onerussian.com
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
On Mon, 2 Jan 2012 09:40:33 -0200 Henrique de Moraes Holschuh h...@debian.org wrote: On Mon, 02 Jan 2012, Karl Goetz wrote: to fix a tiny problem which presents itself just for the length of the upgrade process, if at all. Correct. It's an option nevertheless, so I mentioned it. Sorry if I've misunderstood, but doesn't this problem manifest for *anyone* trying to ssh from a wheezy system to a squeeze system? Only if you're tunelling the screen protocol itself over ssh, which is not how it is normally used. In fact, I am not even sure you can do it that way... Silly me :/ kk -- Karl Goetz, (Kamping_Kaiser / VK7FOSS) http://www.kgoetz.id.au No, I won't join your social networking group signature.asc Description: PGP signature
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Hi Yaroslav! Yaroslav Halchenko wrote: I strongly recommend this solution, along with a proper debconf notice. [...] /tmp is a good choice because the next reboot will automatically clean up everything (and obviously the old binary will not be needed after a reboot). Thanks for that hint. This sounds better (and especially less messy) than I thought! :-) Thank you Axel for your detailed response and IMHO this is indeed close to an ideal (lightweight, self-cleaning, etc) resolution for this scenario. BTW -- what is the take of standards/practices on having /tmp mounted with noexec [1]? Good point! /run/shm (IIRC formerly /dev/shm) likely would be an alternative option, too. I just wondered if that might be worth a check/warning during moving the binary Indeed. Thanks for this hint! Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120103061704.gu20...@sym.noone.org
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Hi Marco, Marco d'Itri wrote: 1) Let the preinst maintainer script make a copy of the old screen binary, provide a script to clean up this mess afterwards, inform the user via debconf about the issue and his possibilities (where the copy of the old screen is, etc.). Disadvantage: It's a non-dpkg-managed mess. I strongly recommend this solution, along with a proper debconf notice. [...] /tmp is a good choice because the next reboot will automatically clean up everything (and obviously the old binary will not be needed after a reboot). Thanks for that hint. This sounds better (and especially less messy) than I thought! :-) 2) Make screen 4.0.3 and screen 4.1.0 installable at the same time, i.e. give them different source and binary package names. This would require a great amount of work I fear so, yes. to fix a tiny problem which presents itself just for the length of the upgrade process, if at all. Correct. It's an option nevertheless, so I mentioned it. Thanks for your insight! Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120102031344.gl20...@sym.noone.org
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Axel Beckert a...@debian.org writes: A) Add an option to screen so the screen client speaks the old protocol to the running server protocol. This IMHO would be best solution and one without a big impact. It's also something which could be Debian-only, i.e. a patch. (It of course would be better if upstream could be convinced to add such an option. :-) That does sound like the best option. Reading upstream's latest response, they don't seem to have expressed a position on accepting such a change if someone does the work to implement it. B) Take care that nobody upgrades the screen package while running inside a screen without being aware of the possible problems. There are few ideas how to implement this: 1) Mention it in the release notes that screen has to be upgraded to the very end of the dist-upgrade process if the dist-upgrade is running inside screen. Disadvantage: Many admins don't read the release notes. […] 3) Tell people via the release notes that they should not run the dist-upgrade inside screen, but inside tmux instead. Disadvantage: Many admins don't read the release notes. The release notes (by which I assume you mean ‘changelog’ and ‘changelog.Debian’) are not displayed by default, but I think the ‘NEWS.Debian’ file is intended for this sort of “you need to know this before upgrading the package to this version” information. See the Developer's Reference §6.3.4. -- \ “I am as agnostic about God as I am about fairies and the | `\ Flying Spaghetti Monster.” —Richard Dawkins, 2006-10-13 | _o__) | Ben Finney b...@benfinney.id.au -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ty4e20xo@benfinney.id.au
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Hi Ben, Ben Finney wrote: B) Take care that nobody upgrades the screen package while running inside a screen without being aware of the possible problems. There are few ideas how to implement this: 1) Mention it in the release notes that screen has to be upgraded to the very end of the dist-upgrade process if the dist-upgrade is running inside screen. Disadvantage: Many admins don't read the release notes. […] 3) Tell people via the release notes that they should not run the dist-upgrade inside screen, but inside tmux instead. Disadvantage: Many admins don't read the release notes. The release notes (by which I assume you mean ‘changelog’ and ‘changelog.Debian’) Nope. I mean the release notes as published by Debian when releasing a new stable release, i.e. http://www.debian.org/releases/stable/releasenotes tracked at http://bugs.debian.org/release-notes but I think the ‘NEWS.Debian’ file is intended for this sort of “you need to know this before upgrading the package to this version” information. It's already in there since the last upload to experimental. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120102042948.gn20...@sym.noone.org
Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
On Mon, 2 Jan 2012 04:13:44 +0100 Axel Beckert a...@debian.org wrote: Hi Marco, Marco d'Itri wrote: 2) Make screen 4.0.3 and screen 4.1.0 installable at the same time, i.e. give them different source and binary package names. This would require a great amount of work I fear so, yes. to fix a tiny problem which presents itself just for the length of the upgrade process, if at all. Correct. It's an option nevertheless, so I mentioned it. Sorry if I've misunderstood, but doesn't this problem manifest for *anyone* trying to ssh from a wheezy system to a squeeze system? thanks, kk -- Karl Goetz, (Kamping_Kaiser / VK7FOSS) http://www.kgoetz.id.au No, I won't join your social networking group signature.asc Description: PGP signature