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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
]] Axel Beckert I see the following options: [...] 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. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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.
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
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Axel Beckert a...@debian.org writes: 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, 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). -- Romain Francoise rfranco...@debian.org http://people.debian.org/~rfrancoise/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
On Mon, Jan 2, 2012 at 03:18:34 +0100, Axel Beckert 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? Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
Hi Yaroslav, Yaroslav Halchenko wrote: pardon my blunt question: No, this question is completely valid and understandable and came up already in the two mentioned bug reports (#644788 and #649240). but is there really possibility to have them 'fixed'? Well, there are several ways to fix this, some are surely less perfect and less favourable solutions, but then again -- as you correctly state -- the perfect ones may not be possible. But we have to choose at least one solution because otherwise the dist-upgrade to Wheezy will be very ugly (and therefor not debian-like) for those who run it inside a screen session remotely and the network connections dies after screen has been dist-upgraded. (So IMHO there is no option to do nothing at all. ;-) I am reading upstream response just as a statement that it can't be achieved due to a chance in protocol... Yep. I see the following options: 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. :-) 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. 2) Fail in the preinst maintainer script if screen server processes are running like udev did from Etch to Lenny if not upgraded together with the kernel. Disadvantage: According to Steve Langasek this could be very ugly, so I suggest to inform via debconf about the issue and let the user decide if he wants to continue, abort (or maybe get a shell to connect to that screen session and close it) 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. People may still distrust tmux for such an crucial task or just may not be comfortable with the parts where tmux's behaviour differs from screen's behaviour. C) Provide both, screen 4.0.3 and screen 4.1.0 binaries. Again, here are more than one option to do so: 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. 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. Disadvantage: Dependencies between those packages needed for proper Wheezy migration not obvious. We'd need something like if screen sessions are running, pull in screen-4.0.3 and screen-4.1.0, but just pull in screen-4.1.0 if no screen session is running, but of course this is impossible just with dependencies. Additionally, I'm not 100% (but let's say 90% :-) convinced that these changes necessarily had to be incompatible. But changing them back (if possible) would surely have some impact the other way round for those already running git snapshots running with the current protocol version. So there may be also an option D: D) Convince upstream to make the new protocol (which includes password protected screen sessions even after reattaching) compatible to the old protocol. IMHO option A would be the most preferable one, D seems less realistic, C2 is realistic but quite some work, B1, B3 and C1 are ugly, and B2 is said to possibly become ugly, too. So my current plan is that if nobody manages A, I'd have a closer look at C2 and if that's not possible or too complicated, I'd go with B2 and the mentioned Debconf questions as the last resort. 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
On Jan 02, Axel Beckert a...@debian.org 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 As long as the needed patch is simple. But if it were, this would probably already have been solved. 2) Fail in the preinst maintainer script if screen server processes are running like udev did from Etch to Lenny if not upgraded together with the kernel. The abort notice should be provided by debconf before the upgrade process is started, indeed. 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. If screen is running, the admin will be able to choose between: - abort the upgrade, upgrade screen and its dependencies and then start again the full upgrade - continue the upgrade while knowing that the old binary will still be available in /tmp/old-screen.$RANDOM/ or something /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). 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 to fix a tiny problem which presents itself just for the length of the upgrade process, if at all. I believe that this is a textbook example which shows how trying to implement the perfect solution which will beautifully cover all corner cases has indefinitly stalled development on the package. Do not try to fix everything, you should aim to provide a reasonable solution which will solve the most common cases. -- ciao, Marco signature.asc Description: Digital signature
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
