Ubuntu

Byobu should be enabled by default for initial login to Ubuntu Server

Reported by Ciemon Dunville on 2010-05-27
204
This bug affects 44 people
Affects Status Importance Assigned to Milestone
Ubuntu Server papercuts
Undecided
Unassigned
byobu
Wishlist
Unassigned
byobu (Ubuntu)
Wishlist
Unassigned
Maverick
Wishlist
Unassigned

Bug Description

Server users typically use screen to maintain a persistent, but detachable session on their servers to enable processes to continue whilst disconnected.

Byobu presents the most important server status information to a user, taking up only two lines of a terminal session to present that information, negating the need to run commands when a user remembers to check system status information.

It would seem an obvious choice to enable byobu by default on connection to a server, allowing the user to see near real time, configurable, status information about the server, combined with the detachable nature of screen. The default installation should provide minimal information, with Menu:<F9> showing so that new users are able to quickly configure it.

Martin Meredith (mez) wrote :

I disagree.

There are limitations to using byobu as default, the main issue being that the scrollback doesn't work as you'd expect (you cant use a normal graphical terminal's scrollback functionality) - which is one of the reasons that people won't take it up at my workplace. It also interferes with some of the standard commands for vim (mainly for switching between tabs)

While, for those experienced, they can get around these, they are major problems for those not used to screen/byobu

Changed in byobu:
status: New → Triaged
importance: Undecided → Wishlist
Changed in byobu (Ubuntu):
status: New → Triaged
importance: Undecided → Wishlist
Changed in byobu:
status: Triaged → Invalid
C de-Avillez (hggdh2) wrote :

I would be nice to have more details on the issues raised by Martin.

Nick Barcet (nijaba) wrote :

While not enabling enabling byobu by default means that:

 - users are very unlikely to discover it, and its many benefits,
 - there is no standard way status messages can be easily displayed on a server console,
 - it is impossible to detach from a session while leaving a program running,

enabling it does not seem to break anything but a scrollback habit and disabling it is as simple as selecting the menu and the right function. It will NOT:

 - break any form of server automation that I know of
 - render the server unuseable if a byobu version is buggy, as it will simply return the user to the regular console
 - prevent anyone from using any programs

This is therefore a +1 for me.

To comment on the scrollback issue, it just means that, by default, the key combinations <shift><pgup> or <shift><pgdn> will not allow someone to scrollback in the terminal buffer unless the terminal is first put into scrollback/copy mode by pressing F8, which is, I beleive, clearly documented in the byobu manpage and online help.

Dustin Kirkland  (kirkland) wrote :

I concur with Nick, except to correct him that F7 enters scrollback mode (rather than F8).

Ciemon Dunville (ciemon) wrote :

Having spoken with Martin on irc, his co-workers use Ctrl-Alt-PgUp (or Down) to switch Vim tabs. Of course there are other ways of switching tabs; the main documented keystroke being gt.

Joey Stanford (joey) wrote :

Would save me time on setup. I use this as the default for all Login/Console windows on all machines, both server and desktop. +1 from me.

Thierry Carrez (ttx) wrote :

Server papercuts are for obvious fixes, not for conflictual decisions. Enabling byobu by default on Ubuntu Server was discussed at UDS-M and the idea was postponed by server engineering management... so this is not valid as a papercut.

Changed in server-papercuts:
status: New → Invalid
Ciemon Dunville (ciemon) wrote :

Thierry, this bug has nothing to do with "conflictual decisions". It is the opinion of an Ubuntu user on how critical server information can be best served to a user, as I've detailed in the description.

The discussion at UDS, and the outcome have no influence on whether this a valid papercut, the suggestion has been discussed, that is all.

The definition of a papercut at https://wiki.ubuntu.com/PaperCut is: "a trivially fixable usability bug that the average user would encounter in default installation of Ubuntu or Kubuntu Desktop Edition" and I believe that this bug fits that definition.

Server users cannot currently, quickly and easily see server status/information which is trivially fixed by enabling byobu for the initial login.

Serge Hallyn (serge-hallyn) wrote :

Sorry, I'm probably missing some background, but why can't the admins do

   ssh -t myserver byobu

?

Thierry Carrez (ttx) wrote :

@Ciemon: Your definition is a "Papercut" and only applies to the Desktop Edition (as your own definition points out). A "Server papercut" is defined at https://wiki.ubuntu.com/ServerPapercutsMSpec. This includes the following acceptance criterium:

"Obvious and non-controversial solution"

Moving to using byobu by default as the shell is typically a controversial move, hence the rejection as a server papercut. That does not mean the wishlist bug in itself is invalid, just that trying to solve it through the Server Papercuts initiative is not appropriate. The Server Papercuts initiative is there to catch low hanging annoying fruit, not to fast-track controversial options.

Thierry Carrez (ttx) wrote :

@Serge: the admins can easily toggle byobu to run by default. The issue here is discoverability of the feature, not the feature itself.

Malcolm Scott (malcscott) wrote :

In an environment with a number of Ubuntu servers, it is common (here, anyway) for a user to only run byobu on one of them, from which ssh connections to the other servers are maintained -- ssh from one server to another will take up another two lines of the terminal and provide confusing nested windows. Whilst I agree that it would be good to make this feature more discoverable, I do not think that enabling byobu by default is a good idea, for this reason and those presented in comment #1.

Clint Byrum (clint-fewbar) wrote :

So, after the heated debate at UDS, I turned byobu on for a couple of my own personal servers (1 Karmic , 2 CentOS).

I have turned it off on one of those machines since, but rather enjoy it for the other two. The main reason is that I ssh into that box 2 or 3 times a day from different places, and I don't necessarily want to see what I saw. I just want a shell prompt to run something on. byobu gets in the way of that.

I think this is a case of what kind of car should Ubuntu Server be?

Are we trying to produce the feature rich ultra comfortable 7 series luxury sedan, or the spartan, agile, powerful M3 sport coupe?

People can always add speakers and a nav computer to the M3, but you can't rip all the stuff out of the 7 series. So I actually think we should strive for a lean, powerful machine, and leave byobu just the way it is.

-1

Dustin Kirkland  (kirkland) wrote :

I'll just note once again that if you want to ssh into a server that would normally launch byobu, but instead NOT launch byobu on time, just use:

  ssh -t yourserver bash

-1 ...fully agree with Clint (and love the BMW references). Another opinion is that byobu is unnecessary, and ugly.

*sigh* This is they type of stuff that makes long-time sysadmins say horrible things like "Ubuntu is a desktop OS." Really, I'm not trying to be a troll here… I'm sure many people disagree, but I believe the anti-byobu contingent is large enough that this would offend too many.

Timothy R. Chavez (timrchavez) wrote :

Sorry, I'm a bit late to the party.

How would this be achieved?

If it's a matter of putting 'exec /usr/bin/byobu-launcher' into .bash_profile, I have at least one concern that is security related. Based on my experience w/ byobu-launcher, it will either create a new session or attach you to an existing one. This is where the problem lies, IMO. Based on this methodology, I think making byobu the default session manager will make Ubuntu servers more attractive targets for would-be attackers.

For example:

I log in, 'exec /usr/bin/byobu-launcher' creates a session, I su to root (why would I do this!?), and then I disconnect without explicitly exiting the session (e.g. I close a window, I experience power failure, etc). Anyone with access to my user account effectively has access to the root user as well because when they log in as me, byobu-launcher will attach them to the existing session which is currently sitting in a root shell. Even if they don't gain root access this way, byobu has definitely made it easier for them to snoop on the user by allowing them to share the same session. Do I have this correct or am I completely off base?

I think it would be much better if /usr/bin/byobu-launcher re-authorized the login user by forcing them to re-authenticate the effective user when attaching to a session in which the effective user differs from the login user... if that makes sense.

The other concern I have has to do w/ automation. I could imagine some organization has written a set of expect scripts (why!?) that among other things, log into systems, perform some tasks, and then log out....

foo@localhost:/home/foo# logout
bash: logout: not login shell: use `exit'

It's a relatively simple fix / workaround, but annoying none-the-less.

Malcolm Scott (malcscott) wrote :

Re #14 (Dustin Kirkland):

Thanks; "ssh -t server bash" is a workaround I had somehow failed to notice. I suggest that it should be documented somewhere very obvious if byobu becomes enabled by default though.

Re #16 (Timothy R. Chavez):

> Anyone with access to my user account effectively has
> access to the root user as well because when they log
> in as me, byobu-launcher will attach them to the existing
> session which is currently sitting in a root shell.

Good point in that byobu does effectively subvert the per-tty tickets of sudo: a byobu session will contain a persistent tty and thus sudo tickets will be shared amongst separate ssh connections.

However I have never quite been convinced by sudo's security model in this regard (and this is equivalent to the scenario you present where a root shell is left open inside byobu): if someone gains access to a sysadmin's personal account, it is a simple matter for the attacker to surreptitiously install hooks such that the next time the sysadmin elevates to root (via sudo, or su, or anything else) the attacker elevates to root too.

So in my opinion byobu bypasses a bogus security feature... maybe this makes things slightly easier for the attacker but not considerably so.

> The other concern I have has to do w/ automation. I
> could imagine some organization has written a set of
> expect scripts (why!?)

I echo the "(why!?)" -- running expect on a shell is pretty bizaare and not something I would worry about. Shell scripts are a much saner approach and if invoked sensibly, e.g.

  ssh user@host some-remote-script.sh

or even like

  ssh user@host < some-local-script.sh

byobu will not be invoked as bash will not be running interactively and so .bash_profile will not be sourced.

(NB: these opinions are entirely mine and I certainly don't speak for the byobu maintainers or Ubuntu.)

Dustin Kirkland  (kirkland) wrote :

Won't fix in Maverick. Maybe one day, though...

Changed in byobu (Ubuntu Maverick):
status: Triaged → Won't Fix
Changed in byobu (Ubuntu):
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package byobu - 4.46-0ubuntu1

---------------
byobu (4.46-0ubuntu1) precise; urgency=low

  * debian/control: LP: #887344
    - promote tmux to a 'recommends'; will 'depend' on it soon
  * === added directory etc/profile.d, etc/byobu/Makefile.am,
    etc/profile.d/Makefile.am, etc/profile.d/Z97-byobu.sh, Makefile.am:
    - LP: #586546
    - Enable any user to remotely opt into launching byobu by default,
      using an LC_BYOBU=1 environment variable, which is transmitted over
      SSH
  * configure.ac, debian/install, etc/byobu/Makefile.am,
    etc/profile.d/Makefile.am:
    - fix installations to /etc
  * usr/bin/byobu, usr/bin/byobu-reconnect-sockets,
    usr/share/byobu/profiles/tmux: LP: #883637
    - fix reconnection to SESSION_MANAGER and DBUS_SESSION_BUS_ADDRESS
    - add C-F5 key to tmux profile
  * usr/bin/byobu-ctrl-a, usr/share/byobu/profiles/tmux: LP: #887387
    - support F12 as escape key in tmux mode
    - reorder byobu-ctrl-a to offer screen first, then emacs mode
    - make byobu-ctrl-a slighty more compatible with tmux (not quite
      there yet...)
  * usr/bin/byobu: LP: #713879
    - add ulimit checks to byobu -v
  * usr/lib/byobu/.constants:
    - don't use UTF8 C an F for now
  * usr/lib/byobu/network: LP: #880410
    - localize some variables, fix variable colision with cpu_temp
  * debian/control:
    - bump standards version
  * debian/install, debian/rules, etc/byobu/Makefile.am,
    etc/profile.d/Makefile.am:
    - fighting with autoconf to get shtuff installing in /etc, argh
 -- Dustin Kirkland <email address hidden> Mon, 31 Oct 2011 09:46:46 -0400

Changed in byobu (Ubuntu):
status: Fix Committed → Fix Released
Dustin Kirkland  (kirkland) wrote :

Okay, so after pushing Byobu for several years as a default command line experience within Ubuntu, I'm raising the white flag and surrendering :-(

I've just committed revisions 1728 and 1729 to lp:byobu that approaches this from the opposite direction -- enabling Byobu lovers an easy way to ALWAYS enable byobu on launch. As of byobu-4.46, you should be able to simply add to your local system's ~/.bashrc: "export LC_BYOBU=1", and everywhere you ssh into, that has byobu >= 4.46, should launch automatically. Basically, I've added this code to:

#/etc/profile.d/Z97-byobu.sh:
if [ "$LC_BYOBU" = "1" ] && [ -r "/usr/bin/byobu-launch" ]; then
        . /usr/bin/byobu-launch
fi
true

This could, perhaps, be a candidate for SRU to 11.10, if smoser and utlemming want to back out the byobu-by-default setting there.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers