Re: Whatever happened to...
+1 Sent via BlackBerry by ATT -Original Message- From: Evan eapa...@gmail.com Date: Tue, 9 Jun 2009 17:57:04 To: Ubuntu Development Discussion Listubuntu-devel-discuss@lists.ubuntu.com Subject: Whatever happened to... -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Is disabling ctrl-alt-backspace really such a good idea?
If your X crashes from time to time that's unfortunate for you, but a good thing for Ubuntu as you get the chance to report and track down a bug. Come on, are you kidding me? That attitude towards user-friendliness isn't going to help Ubuntu at all. Sorry but a users X issues doesn't help Ubuntu. CTRL+ALT+BACKSPACE is a standard for many people. Though it isn't something that would normally be used, but when needed saves a lot of time. But get serious, having to reboot your system isn't going to increase bug reports for X crashes. In fact I'd argue to say people will be less likely to file a bug report, due to the added time and aggravation of rebooting the system. Point is, the ability to quickly and easily restart X is an invaluable feature. It seems like a regression to remove such a standardized usage. --Original Message-- From: Markus Hitter Sender: ubuntu-devel-discuss-boun...@lists.ubuntu.com To: Liam Zwitser Cc: ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Is disabling ctrl-alt-backspace really such a good idea? Sent: Feb 10, 2009 10:02 Am 16.01.2009 um 16:58 schrieb Liam Zwitser: I assume that most people don´t want to have to restart their pc when the GUI chrashes. I assume most people don't want their GUI to crash at all. That's a serious data loss each time, after all. If your X crashes from time to time that's unfortunate for you, but a good thing for Ubuntu as you get the chance to report and track down a bug. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss Sent via BlackBerry by ATT -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Fwd: Is disabling ctrl-alt-backspace really such a good idea?
Even if a new user is unfamiliar with the key combination, it only takes a little education OR them doing it once. Lessons are learned hard. Should we remove all the abilities that may damage the system? Where does the line get drawn? The C-A-B is an easy thing to learn and avoid, but a powerful resource when needed. Sent via BlackBerry by ATT -Original Message- From: Dylan McCall dylanmcc...@gmail.com Date: Tue, 10 Feb 2009 07:02:51 To: Clive Wagenaarclivewagen...@gmail.com Cc: ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Fwd: Is disabling ctrl-alt-backspace really such a good idea? I agree with this guy, have it on by default, noobs can use GUI to switch it off. Else, millions of users will be doing this on first boot up: alt f2 gksudo gedit /etc/X11/xorg.conf Section ServerFlags Option DontZap no EndSection The important thing is that those millions of users actually don't mind tinkering with xorg.conf and probably do anyway. The users we are trying to help, however, Don't Know The Key Combo Exists, or that xorg.conf exists, or that they need to explicitly tell the system how to be easier to them, until it is too late. They don't want to do any extra configuration after installing the operating system. Those millions of power-users do. It astounds me how people just forget about Ubuntu's goals and aspiritions in light of this issue. It isn't doing much for user friendliness when the community of contributors is using bad names on those new users Ubuntu strives to be gentle to and then treating them like outsiders. It isn't /likely/ for someone to hit C-A-B (although it's been done once or twice by yours truly, particularly with graphics tools), but the immediate issue is that we have a key combination which, without a moment's question, eradicates one's session from existence. No session saving, no notice, no sensitivity to whether the keyboard is grabbed or another application is handling the event. It just happens no matter what. Further, it relies on common keys. Sysrq K is alright since nobody tends to use the Sys RQ key, but Ctrl and Alt are both everyday modifier keys and Backspace is a natural key for deleting stuff. We want our users to feel free exploring Ubuntu without the risk of wiping out the system (within reason, of course). Hopefully they can gain a trust of themselves and the system that way, start paying more attention to the text on the screen and learning what it all means. One thing I know is that a single catastrophic event like tinkering led to the loss of two hour's work when I pressed Ctrl Alt Backspace causes someone to doubt the value of that exploring. Then there's another user reliant on others for resolving all issues related to the computer. Something interesting I've learned in an Ubuntu Forums thread is that a surprising number of people who want this key combo to stay don't actually use it for its intended purpose (to reset X when it is crashed). Instead, they use it as a shortcut for logging out. Doing that is risky, messy and inadequate. Perhaps if logging out (with session saving) was mapped to Ctrl Alt Backspace we wouldn't have as many bothered users. Bye, -Dylan -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: rename system-cleaner-gtk to cruft-remover-gtk
Just to be clear, that was my point: just because a package is installed from a deb and not a repo does not mean it is unwanted/unneeded/cruft. But if people are installing apps from other sources, maybe we should include such packages in the official repos/sources, etc. Clearly this is not the sole purpose of this application, is a good example of the need for a new name. One which more clearly defines the features/purpose. Just for some thought, and words ideas... * System Defaulter * Baseliner * Upgrade Cleanup Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Charlie Kravetz [EMAIL PROTECTED] Date: Mon, 3 Nov 2008 07:22:55 To: ubuntu-devel-discuss@lists.ubuntu.com Cc: [EMAIL PROTECTED] Subject: Re: rename system-cleaner-gtk to cruft-remover-gtk On Mon, 3 Nov 2008 13:27:29 + Justin M. Wray [EMAIL PROTECTED] wrote: Maybe this is my misinterpertation of the purpose of the application, but I am unsure that a whitelist/blacklist would be the right solution. Correct me if I am wrong, but the tool removes apps that are not in the repository (for whatever reason; manually install, obsolete, etc). Why would we white list such apps? If such a use case exists for the package to stay on the system (example - manually installed apps) should the app not exist in the repository? On that note, maybe we can obtain statistics (with permission) of debs that are installed manually and do not exist in the repository. This data can then be used to prioritize applications that need packaging or upgrading. We can base priority on the number of instances we see...etc. Thought? Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: (``-_-´´) -- Fernando [EMAIL PROTECTED] Date: Mon, 3 Nov 2008 11:34:24 To: ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: rename system-cleaner-gtk to cruft-remover-gtk I have apps that I installed using a .deb file, but never added the repository I downloaded them from to sources.list. I don´t believe that the fact that the app has been installed is enough to assume that it is listed in the repositories. There are many apps available which official repositories do not list, and the user can install on their own. That they elect not to add the repository to the list should not be reason to say the app is not needed by the user. -- Charlie Kravetz Linux Registered User Number 425914 [http://counter.li.org/] Never let anyone steal your DREAM. [http://keepingdreams.com] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: rename system-cleaner-gtk to cruft-remover-gtk
Maybe this is my misinterpertation of the purpose of the application, but I am unsure that a whitelist/blacklist would be the right solution. Correct me if I am wrong, but the tool removes apps that are not in the repository (for whatever reason; manually install, obsolete, etc). Why would we white list such apps? If such a use case exists for the package to stay on the system (example - manually installed apps) should the app not exist in the repository? On that note, maybe we can obtain statistics (with permission) of debs that are installed manually and do not exist in the repository. This data can then be used to prioritize applications that need packaging or upgrading. We can base priority on the number of instances we see...etc. Thought? Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: (``-_-´´) -- Fernando [EMAIL PROTECTED] Date: Mon, 3 Nov 2008 11:34:24 To: ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: rename system-cleaner-gtk to cruft-remover-gtk -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
Andrew, In general a one time emergency, and remote help will be two different situations. But I see no reason the split the ability into two different projects/solutions, and the end-result is the same: a remote user gains access (securely) to your system, in order to fix a problem. I also see the functions/process that we are working out in the so-called remote recovery soultion being reused for a remote help solution, and feel that forcing another reinvention of the wheel, or a serperate package with the same end result pointless. I feel it would be far more simple to add a GUI control (VNC) option to the exisiting setup, allowing the helpless user or expert pick the correct course of action. I would obviosuly not waist my time using VNC to open a shell and make changes to complex system options if the user would gain no advantage by me doing so. But at the same time, it would pain me as well as the user to have two different remote assistance options, in which I would need to explain the diffrence. Maybe I am being a bit extreme about the extra step involved in selecting the correct soultion (if they are split), but at the same time having them combined would truly make everything easier. Package managment, bugs, etc, would all be linked anyway. I agree that the use of SSH keys in a one-time situation would be far more complex, although I think email/web would be a far better way to transfer the key then mailing them, even in a long term situation. Nonetheless the password solution should be fine, with the proper security precautions. The addition of the chroot jail will surly allow the majority of the helpers to feel safe. It should add that extra layer of security needed in the password situation. Altough it may be wise to disable further logins, and/or change the password after the connection has been made. I think adding a small (obvisouly simply) script for: cat ~remote-recovery/shell_out cat ~remote-recovery/shell_in Would be a wise option to streamline the process, but having the ability to split input and output will make this a truly robust solution. Another note on the security front, and the user learning front. I think it would be wise to echo the input and output to the recovery system/helpless user. This would allow them to follow along with the recovery process, and if need be interact directly. Just like VNC, they would be able to watch and possible learn, and chime in with enviroment related questions when need be. But let's for a moment assume they have no idea what the problem is, and will surly not understand the solution. The ability to watch the process does add an extra layer of security. The helpless user can monitor what the helper accesses etc. It should at the very least give them ease of mind. It is far from fool proof, but should be an extra valuable layer, and the educational benifit is huge. And in the case of no X, this still allows the learning process to take place. And this yet again shows value in a combined solution. I think sound command-line options (like: --cli, --gui, --both [default]) would be the best approch. And with good support from the board/community, we could easily get such a solution setup with an easy to use, easy to find frontend. Shipped by default, as long as the solution is robust enough to cover a number of use cases. The one-time issue, and simple teaching/assistance are not so different in nature. Thoughts? Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Andrew Sayers [EMAIL PROTECTED] Date: Wed, 07 May 2008 14:06:53 To:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier (starting a new sub-thread for a new proposal) I'm currently swinging back towards remote recovery and remote help being distinct problems that need different solutions. There are three reasons for that: 1) As I mentioned in a previous post, remote recovery needs to be done in an extremely defencive way. Some of the things that could get users into a mess include: * Failure to mount /home * Deleting /root and/or the root account * A half-installed upgrade that leaves sshd_config messed up * /, /tmp/, /var etc. mounted read-only None of these are problems that you need to worry about in the remote help case. 2) While I definitely agree with people that say remote help should be an over the virtual shoulder exercise so that the user can learn some things, remote recovery is generally necessary when they've got themselves into a situation where they don't understand the problem, and wouldn't understand the solution. 3) From the point of view of remote recovery, the problem with public keys is that they're very long and difficult to type. In a remote help situation, you post someone a floppy disk with your public key on, whereas with recovery, you'd have to spell it out over
Re: Suggestion to make remote recovery easier
I agree with your generalization, and ordering. It provides fault tolerance, security, and usability. Making the entire process esasier (the main goal of this project). I am unsure if I feel adding a numeric value to each option is needed, when simple programming conditions can handle the tasks. I think the numbers (bids) adds some uneeded complexity/confusion. The robustness and power of the solution we are now talking about exceeds the power of simple shell scripts and code hacks, thus needing a higher level language. But I personally see this as a good thing (speed, security, etc). I think it would be best to go through each option as you have them listed, and try them, once. If it works use it, if not move on. Only prompt the user if we get to an insecure option. But at the same time I think the helpless user should have the ability to over-ride the option, or the helper over-ride the option (with approval from the helpless) at start. A GUI front-end would le such choices be easily made. And an expert can easily tell the helpless to type --telnet at the end of the command. One more note, if we do use something like 'c' we could easily add a socket into the app itself. So we would have the following options, in said order: 1) SSH 2) bash-socat-cryptcat 3) bash-socat-netcat 4) bash-socat 5) telnet 6) bash-socket (I've changed the order around a bit, to what I think would more secure and sound.) And after connection, having the following recovery options: 1) A VNC-based GUI 2) An X-based GUI (for e.g. broken video cards) 3) A screen-based TUI (for those of us that love screen) 4) A pty-based TUI (so that editors like vi work) 5) A pipe-based TUI (for dire emergencies) 6) A non-interactive mechanism for swapping keys 7) Custom command (Which should have been selected when the recovery-command was first run.) It seems like we are on track, what do you think? Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Andrew Sayers [EMAIL PROTECTED] Date: Wed, 07 May 2008 18:57:41 To:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier Having looked quickly at cryptcat, it seems like some interfaces would be best served by cryptcat+socat, so that you can get security and a pseudo-terminal. To generalise your idea even further, how about a bidding system? For example, say the expert asks for a forward remote shell on the friend's computer: First, the program asks for a shell connection to the specified IP address: * SSH doesn't have that IP address in its known_hosts file, so it bids 90 * bash can create a login, but has to sub-contract creation of the PTY. It bids 99, on condition that someone else handle the PTY * telnet can't do security, so bids -1 (i.e. get confirmation before continuing) Since a bid exists that has conditions, we do a second round of bidding. In the second round, the program asks for a PTY on the specified address: * socat bids twice: - 99, on condition that someone else handle the connection - 49 if it has to handle the connection itself Since there's still a bid with conditions, the third round asks for a connection to the server: * SSH still doesn't know the hostname, and isn't designed for that particular purpose, so bids 80 * cryptcat doesn't know that host name, so bids 90 * netcat can't do security, so bids -1 SSH's bid is ignored, because there's already a higher bid with SSH in it Since no more bids have conditions, the various options are ranked first according to the lowest bid in the chain, then according to the number of links in the chain: 1) SSH (90/1) 2) bash-socat-cryptcat (90/3) 3) bash-socat (49/2) 4) telnet (-1/1) 5) bash-socat-netcat (-1/3) Each of these is then tried in order. If the program gets all the way down to (4) without success, it asks the expert whether he wants to try insecure connection methods (there might be nothing wrong with telnet - for example, if the computers are already connected over a modem). - Andrew Justin M. Wray wrote: Yes, this seems to be the robust sort of approch that seems to cover the most use cases and works at a very low level. Thoughts on crytpecat verses socat? It has the benifit of being more secure. I think the solution should work as such: 1). Try SSH, if fail then, 2). Try cryptcat, if fail then, 3). Try socat There will be times when cryptcat will be broken (lib issues etc), so having socat as the last resort seems safe. But for the sakof passwords and data I do not think it should be the first option. In addition SSH is far more robost with added complexity, if it is avaliable, I think it should be used. Thoughts? The ability to have: 1) A VNC-based GUI 2) An X-based GUI (for e.g. broken video cards) 3) A screen-based TUI (for those of us that love screen) 4) A pty-based TUI (so that editors like vi work) 5) A pipe-based TUI (for dire emergencies) 6
Re: Suggestion to make remote recovery easier
I see no reason why we can't (even with C) come up with a universal package, that other distros can use. (Most programs are C, the diffrence is normally packaging). But if we can complete this is shell code, there is the benifit of an expert being able to quickly change the code, without needing to recompile, etc. Let me know how the dash adventure turns out. We can then go from there. Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Andrew Sayers [EMAIL PROTECTED] Date: Wed, 07 May 2008 20:07:13 To:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier We're certainly getting there! I haven't yet given up hope of doing this with a shell script (evidentiary question again). The benefit of a shell script is that it leaves open the possibility of packaging a lite version of the program as a single architecture-neutral file, so that we can support users of other unixoid systems that can download a script. The reason I went for numbered rankings was that it makes it easy to compare two modules that don't know anything about each other. If every module needs a greater than/less than function that knows about every other module, that makes O(n^2) work for us every time we want to add a new module. Or more precisely, O(n^2) work for some poor expert we'll never meet that happens to need a particular module for his special case. On the other hand, if you have a non-numeric solution with linear complexity, I always like being proved wrong about these things :) The choice of interface module needs to be made before the choice of lower-level module, because not all interfaces have the same requirements. For example, VNC needs a TCP socket, which has to be passed in the parameters to SSH. Finally, I agree that a GUI would be a good default choice here, although it needs to be written in such a way that the ncurses/plaintext fallback looks quite natural to the user when everything goes wrong. However, I don't really do GUI programming, so it's not something I would be able to do myself. I'm now going to download dash and see whether I can fight my way out of that little box. If not, C it is. - Andrew Justin M. Wray wrote: I agree with your generalization, and ordering. It provides fault tolerance, security, and usability. Making the entire process esasier (the main goal of this project). I am unsure if I feel adding a numeric value to each option is needed, when simple programming conditions can handle the tasks. I think the numbers (bids) adds some uneeded complexity/confusion. The robustness and power of the solution we are now talking about exceeds the power of simple shell scripts and code hacks, thus needing a higher level language. But I personally see this as a good thing (speed, security, etc). I think it would be best to go through each option as you have them listed, and try them, once. If it works use it, if not move on. Only prompt the user if we get to an insecure option. But at the same time I think the helpless user should have the ability to over-ride the option, or the helper over-ride the option (with approval from the helpless) at start. A GUI front-end would le such choices be easily made. And an expert can easily tell the helpless to type --telnet at the end of the command. One more note, if we do use something like 'c' we could easily add a socket into the app itself. So we would have the following options, in said order: 1) SSH 2) bash-socat-cryptcat 3) bash-socat-netcat 4) bash-socat 5) telnet 6) bash-socket (I've changed the order around a bit, to what I think would more secure and sound.) And after connection, having the following recovery options: 1) A VNC-based GUI 2) An X-based GUI (for e.g. broken video cards) 3) A screen-based TUI (for those of us that love screen) 4) A pty-based TUI (so that editors like vi work) 5) A pipe-based TUI (for dire emergencies) 6) A non-interactive mechanism for swapping keys 7) Custom command (Which should have been selected when the recovery-command was first run.) It seems like we are on track, what do you think? Thanks, Justin M. Wray Sent via BlackBerry by ATT -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
Also, I know a handful of community members chimmed in originaly, but the feedback has subsided. Does anyone else in the community have any comments on our current outlined process? Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Justin M. Wray [EMAIL PROTECTED] Date: Wed, 7 May 2008 19:28:34 To:Andrew Sayers [EMAIL PROTECTED],[EMAIL PROTECTED],ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier I see no reason why we can't (even with C) come up with a universal package, that other distros can use. (Most programs are C, the diffrence is normally packaging). But if we can complete this is shell code, there is the benifit of an expert being able to quickly change the code, without needing to recompile, etc. Let me know how the dash adventure turns out. We can then go from there. Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Andrew Sayers [EMAIL PROTECTED] Date: Wed, 07 May 2008 20:07:13 To:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier We're certainly getting there! I haven't yet given up hope of doing this with a shell script (evidentiary question again). The benefit of a shell script is that it leaves open the possibility of packaging a lite version of the program as a single architecture-neutral file, so that we can support users of other unixoid systems that can download a script. The reason I went for numbered rankings was that it makes it easy to compare two modules that don't know anything about each other. If every module needs a greater than/less than function that knows about every other module, that makes O(n^2) work for us every time we want to add a new module. Or more precisely, O(n^2) work for some poor expert we'll never meet that happens to need a particular module for his special case. On the other hand, if you have a non-numeric solution with linear complexity, I always like being proved wrong about these things :) The choice of interface module needs to be made before the choice of lower-level module, because not all interfaces have the same requirements. For example, VNC needs a TCP socket, which has to be passed in the parameters to SSH. Finally, I agree that a GUI would be a good default choice here, although it needs to be written in such a way that the ncurses/plaintext fallback looks quite natural to the user when everything goes wrong. However, I don't really do GUI programming, so it's not something I would be able to do myself. I'm now going to download dash and see whether I can fight my way out of that little box. If not, C it is. - Andrew Justin M. Wray wrote: I agree with your generalization, and ordering. It provides fault tolerance, security, and usability. Making the entire process esasier (the main goal of this project). I am unsure if I feel adding a numeric value to each option is needed, when simple programming conditions can handle the tasks. I think the numbers (bids) adds some uneeded complexity/confusion. The robustness and power of the solution we are now talking about exceeds the power of simple shell scripts and code hacks, thus needing a higher level language. But I personally see this as a good thing (speed, security, etc). I think it would be best to go through each option as you have them listed, and try them, once. If it works use it, if not move on. Only prompt the user if we get to an insecure option. But at the same time I think the helpless user should have the ability to over-ride the option, or the helper over-ride the option (with approval from the helpless) at start. A GUI front-end would le such choices be easily made. And an expert can easily tell the helpless to type --telnet at the end of the command. One more note, if we do use something like 'c' we could easily add a socket into the app itself. So we would have the following options, in said order: 1) SSH 2) bash-socat-cryptcat 3) bash-socat-netcat 4) bash-socat 5) telnet 6) bash-socket (I've changed the order around a bit, to what I think would more secure and sound.) And after connection, having the following recovery options: 1) A VNC-based GUI 2) An X-based GUI (for e.g. broken video cards) 3) A screen-based TUI (for those of us that love screen) 4) A pty-based TUI (so that editors like vi work) 5) A pipe-based TUI (for dire emergencies) 6) A non-interactive mechanism for swapping keys 7) Custom command (Which should have been selected when the recovery-command was first run.) It seems like we are on track, what do you think? Thanks, Justin M. Wray Sent via BlackBerry by ATT -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel
Re: Suggestion to make remote recovery easier
I will look at your script as soon as I get to my desk. As for the project, let's set it up on sourceforge and on launchad. You want to create the projects, as you came up with the idea to start with? As for a name, I personally donot like remote help, nor remote recover. And Remote Assistance is taken :( We need some good name ideas... Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Andrew Sayers [EMAIL PROTECTED] Date: Thu, 08 May 2008 01:35:50 To:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier Okay, I've got the auction part of the dash adventure completed. In principle, the rest should be relatively easy. The code isn't vastly useful or commented so far, it's just a proof of concept really. The script doesn't prune unlikely matches (e.g. socat+ssh when ssh is already provided), because that doesn't work in the general case: say there are two pipelines, a-b-c and a-c-b. If a-b-c fails, it could be due to a problem in a, b, c, or some interaction between the three. Without knowing more about the error, we can't assume that a-c-b will fail. Here's a rough guide to the script: * Right now, the script reads bids from remote_help.txt, but will eventually take bids by polling a separate set of module scripts * A module script is run with a to-be-decided set of command line arguments. I'm currently thinking it'll be something like: my-module.sh --want remote-shell --remoteuser andrew \ --remotehost example.com this will have to be decided as modules are written - there'll doubtless be some rules, some precedents, and some totally protocol-specific things * Modules that sub-contract part of the job will be assumed to handle subcontracts internally (it's just a matter of calling remote_help.sh again with the appropriate arguments) * Every module is polled in every auction. Inapplicable scripts will return no bids, bids with a variety of subcontractors will return multiple bids * A bid is a line printed on standard output, of the form: integer command line The integer is the bid, the remainder of the line is a command to pass to /bin/sh * The highest bidder is repeatedly run until a bidder returns successfully (note: currently, all bids are run) * This would have been a lot easier if I could rely on `sort` and `head` existing! How should we proceed with this? Set up some space on Sourceforge? Do you have any better ideas for names than remote help? - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
This was the original idea, with the SSH reverse tunnel... It would be the easiest way to deal with the NAT/Firewall issue, without complex pre-help assistance and documentation. It can also be used in conjunction with ACL's (for SSH) and therefore secure the process even more. (Ie, limit SSH to loclhost only) Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Christopher Halse Rogers [EMAIL PROTECTED] Date: Wed, 7 May 2008 11:51:29 To:Andrew Sayers [EMAIL PROTECTED] Cc:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier On 5/7/08, Andrew Sayers [EMAIL PROTECTED] wrote: At this point, I'm trying to walk the line between unrealistic wouldn't it be great if... type ideas and overly-strict reliance on solving the specific problem I have in my head, so I'd like to go back to first principles for a moment. Please tell me if any of these are false: 1) It's common for new Linux users to have a technical friend that deals with their problems. This is a healthy relationship that we should look for ways to support 2) People generally don't formalise that sort of thing until it's too late 3) All Linux users can be behind arbitrarily complex sets of firewalls/NAT, including multiple layers of NAT or firewalls, not all of which are under either user's control 4) We can expect experts to do some considerable work (e.g. installing packages and configuring routers), but non-technical users need simple instructions from the default installation 5) There's some interest in making small changes to the default install to cater to the above issues 6) Since the people in most need of help are more likely to stick to LTS releases, we can afford to add this sort of feature gradually, and see what public reaction is like The basic solution we're looking at here is to make it possible for the technical friend to set up an SSH connection to the non-technical friend's computer, using an account that has some way to execute superuser commands (with sudo or by actually being the root user). This breaks down into three sub-problems: 1) Creating or modifying an account that has the necessary permissions 2) Creating an SSH connection 3) Destroying or reverting an account to its original state In (1) and (3), I had been concentrating on setting up a mechanism to trust someone temporarily, but I now realise that's not a particularly common use case, because if I trust you today, I will probably trust you tomorrow too. Getting people to jump through the same set of hoops every time there's a problem makes life harder than necessary for non-expert users, which I've been complaining about all thread. Reliably doing (2) is a hard problem. The solution I had come up with strikes me as a good solution for a common use case, but there's no way to deal with the general case without introducing more complexity. The other option here might be to flip the problem around: the technical user almost certainly _is_ in control of the NAT they're behind, so you could try writing up a server on the techy-friend side that a client connects to in order to get help. This would have the advantage that you probably don't need to care about what NAT/firewall the helpee is behind, and might also ease some security concerns - the helpee must explicitly start the connection, the helper can start the server only when required, and it doesn't give shell access to anyone who connects. And the obvious disadvantage that this client/server needs to be written. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
Another idea would be to not only tunnel SSH but also VNC. Allowing the newbie to watch the helper do something at times might be the goal, and will make help facilitate learning. In addition the issue might be with a GTK/GUI app, and VNC would be the fastest approch. Just another thought, the security problems tend to be the same, but the same ACLs can be applied (limit to localhost etc). Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Justin M. Wray [EMAIL PROTECTED] Date: Wed, 7 May 2008 03:40:52 To:Christopher Halse Rogers [EMAIL PROTECTED],Andrew Sayers [EMAIL PROTECTED] Cc:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier This was the original idea, with the SSH reverse tunnel... It would be the easiest way to deal with the NAT/Firewall issue, without complex pre-help assistance and documentation. It can also be used in conjunction with ACL's (for SSH) and therefore secure the process even more. (Ie, limit SSH to loclhost only) Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Christopher Halse Rogers [EMAIL PROTECTED] Date: Wed, 7 May 2008 11:51:29 To:Andrew Sayers [EMAIL PROTECTED] Cc:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier On 5/7/08, Andrew Sayers [EMAIL PROTECTED] wrote: At this point, I'm trying to walk the line between unrealistic wouldn't it be great if... type ideas and overly-strict reliance on solving the specific problem I have in my head, so I'd like to go back to first principles for a moment. Please tell me if any of these are false: 1) It's common for new Linux users to have a technical friend that deals with their problems. This is a healthy relationship that we should look for ways to support 2) People generally don't formalise that sort of thing until it's too late 3) All Linux users can be behind arbitrarily complex sets of firewalls/NAT, including multiple layers of NAT or firewalls, not all of which are under either user's control 4) We can expect experts to do some considerable work (e.g. installing packages and configuring routers), but non-technical users need simple instructions from the default installation 5) There's some interest in making small changes to the default install to cater to the above issues 6) Since the people in most need of help are more likely to stick to LTS releases, we can afford to add this sort of feature gradually, and see what public reaction is like The basic solution we're looking at here is to make it possible for the technical friend to set up an SSH connection to the non-technical friend's computer, using an account that has some way to execute superuser commands (with sudo or by actually being the root user). This breaks down into three sub-problems: 1) Creating or modifying an account that has the necessary permissions 2) Creating an SSH connection 3) Destroying or reverting an account to its original state In (1) and (3), I had been concentrating on setting up a mechanism to trust someone temporarily, but I now realise that's not a particularly common use case, because if I trust you today, I will probably trust you tomorrow too. Getting people to jump through the same set of hoops every time there's a problem makes life harder than necessary for non-expert users, which I've been complaining about all thread. Reliably doing (2) is a hard problem. The solution I had come up with strikes me as a good solution for a common use case, but there's no way to deal with the general case without introducing more complexity. The other option here might be to flip the problem around: the technical user almost certainly _is_ in control of the NAT they're behind, so you could try writing up a server on the techy-friend side that a client connects to in order to get help. This would have the advantage that you probably don't need to care about what NAT/firewall the helpee is behind, and might also ease some security concerns - the helpee must explicitly start the connection, the helper can start the server only when required, and it doesn't give shell access to anyone who connects. And the obvious disadvantage that this client/server needs to be written. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Fw: Suggestion to make remote recovery easier
Sending to the list... Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Justin M. Wray [EMAIL PROTECTED] Date: Tue, 6 May 2008 00:08:39 To:Milosz Derezynski [EMAIL PROTECTED] Subject: Re: Suggestion to make remote recovery easier A random password would be far more secure then the password set by the average user seeking this service. Far too often I see someone using things like helpme or password as the normal newbie cannot come up with a complex password on the spot. However, I do agree that I dislike the current way the password is retrevied by the remote-helper. I think it would make more sense to print the random password to the screen and then allow the newbie to read it to the person they trust. Therefore if anythink goes wrong, there is one more layer of security, not that I think the security of a systenm should be left in the hands of a newbie user, it is there system. Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Milosz Derezynski [EMAIL PROTECTED] Date: Tue, 6 May 2008 01:56:50 To:Andrew Sayers [EMAIL PROTECTED] Cc:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier There is IMO no real need for a random password; instead, the user of the machine to be recovered should be allowed to enter a password which he then can tell to the user recovering the machine remotely. This doesn't neccessarily have to be more insecure; a random alphanum password is probably better secured against brute force cracking but i don't like the fact that the computer hands out a password for the user automatically, even if he gets to see it. 2008/5/5 Andrew Sayers [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] : I'm a Linux user of sufficient experience that friends are starting to phone me up when there's a problem with their computer. I guess most people here know how long and painful those conversations can be, so I think it would be better if Ubuntu had a mechanism to let me SSH into people's computers using only instructions that I can describe to newbies over the phone without confusing them. Of course, the problem is doing this in a way that's both secure and robust. I've got an approximate outline of how it would work, so could people tell me how practical this idea is: * There should be three ways to enable remote recovery: - In the GRUB menu, there should be a remote recovery option - From the command-line, there should be a remote-recovery command - From the GUI, there should be System Tools-Remote Recovery * Experts should be able to run /usr/sbin/connect-to-remote-recovery to prepare their system for a remote recovery. Running or connecting to a remote recovery should start by doing the following: 1) Create a remote-recovery user whose home directory is /.remote-recovery, and who has no useful permissions 2) Set their home directory to be chmod 500 3) Create a ~remote-recovery/password file, chmod 400 4) Give the remote-recovery user a random password, and put the password in ~remote-recovery/password 5) If the SSH server isn't running, enable it. If it won't enable, try various things: * If the package doesn't exist, ask if you can install it * If /usr or /usr/bin doesn't exist, check whether they're mentioned in /etc/fstab, and if so, whether they're mentioned in `mount`, then tell the user what's going on, and offer to print the contents of both. Then, running remote recovery should: 1) pop up a warning about how doing this gives complete control of your system to a specified computer, and should only be done at the behest of someone you trust. 2) Add the remote-recovery user to /etc/sudoers 3) Ask for the IP address and remote-recovery password of the person you'll allow access to 4) `ssh [EMAIL PROTECTED] -L22:localhost:` 4a) if that fails, do various diagnostics: * Does the computer have an IP address? Does it have a gateway? * Do a tracepath to that address and print the results 4b) If it succeeds, copy .ssh/id_dsa.pub on the remote host to ~remote-recovery/.ssh/authorized_keys on the local host, then touch .ssh/id_dsa.pub to confirm that the copying is complete 5) Tell the user whether SSH succeeded or failed 6) Inform the user that they can press ctrl-c to quit remote recovery 7) Wait until `w` reports a remote-recovery user logged in 8) Read lines of text and `write` them to the remote-recovery user's tty 9) When the remote-recovery user logs out, ask whether they want to wait for the user to log in again. 9a) If no, go to 10 9b) else go to 7 10) Remove the remote-recovery user, remove them from sudoers, and delete their home directory Alternatively, connecting to a remote recovery should do: 1) Find the IP address(es) of the computer 1a) If any addresses are public (not e.g. 192.168.*.*), print them 1b) Otherwise, tell the user
Re: Suggestion to make remote recovery easier
Andrew, et all, The iptable changes would be a plus, but should be configurable, with sane defaults. I personally would be upset if my current rules were altered without my approval. And it may not be feesable to completely firewall the entire system. In general, if you setup a SSH key (or use one already created), then brute-force shouldn't be a huge issue. Its just the transmission of the password to sudo. And storage thereafter that needs to be secured. The changes to a home directory in /tmp is a smart move, incase something goes wrong, and it is a bit cleaner as well. However on some systems this may not work nicely (noexec on /tmp, etc). Remember not all newbies are completely lost. Someone may want assistance with a complex system or service, and likes the ease of remote recovery, but that doesn't mean they don't manage the system properly, thus the comments above. I find it unwise to make assumtions about the users of a service/solution. It is better to come up with clear defaults, with powerful configuration options. The clean-up scripts is also a wise addition. +1 for the general idea. Remote Help should be easy to obtain, and I too have been on the support call debugging ssh/firewalls before I could work on the true issue. So I welcome the addition of a sound solution. I am on the road at the moment. But in a bit (few hours), I am going to sit down, review what you have already mentioned, and attempt to help workout a clear plan of action. If you have not created a blueprint, you should do so, if you would like I can assist with the creation the blueprint, etc. Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Andrew Sayers [EMAIL PROTECTED] Date: Tue, 06 May 2008 02:51:25 To:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier Milosz Derezynski wrote: There is IMO no real need for a random password; instead, the user of the machine to be recovered should be allowed to enter a password which he then can tell to the user recovering the machine remotely. This doesn't neccessarily have to be more insecure; a random alphanum password is probably better secured against brute force cracking but i don't like the fact that the computer hands out a password for the user automatically, even if he gets to see it. I'm not sure if I follow. If you're complaining about the password on the expert's machine, I'm suggesting that the newbie SSH in to the expert first because I'm happier to assume that an expert would know how to poke a hole through their firewall/NAT router/etc. than I am to assume the same of a newbie. Once that first connection is made, everything gets tunnelled over it. If you're complaining about the password on the newbie's machine, getting them to make decisions and speak passwords is likely to add stress and errors, because they might feel silly about being asked more questions they don't know anything about, might feel silly about spelling a password out phonetically, and might (as Justin pointed out) choose a bad password. Having said all that, how would you feel about these changes: * The connect-to-remote-recovery script on the expert's machine suggests a random password, and asks if you want to choose one manually. * While waiting for an SSH connection, the connect-to-remote-recovery script on the expert's computer keeps an eye on `w` and/or the ssh log, waits for the user to press enter, then does `passwd -d remote-recovery` as soon as they do. That would make brute-forcing an SSH connection to the expert's machine impractical * The remote recovery script on the newbie's computer does `iptables -I INPUT -i ! lo -m state --state NEW -j DROP` (and the same with iptables6) before creating the remote-recovery user, and removes those rules after deleting the user. That would make brute-forcing any connection impossible, even if (for example) the newbie had set himself up a publicly-available FTP server Also, how would people feel about the following changes based on unrelated problems: * Instead of /.remote-recovery, set the user's home directory to /tmp/rr, so it works even on some weird UMSDOS partition, and gets auto-deleted if the computer gets unexpectedly rebooted * Create an init script that deletes the remote-recovery user at boot (again, in case of unexpected reboots) - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Compiz default Application Switcher (Alt+Tab) is difficult to use
chombee, Check out http://compiz.org/Home/Info Mailing list and bug tracker links can be found there, both are hosted by freedesktop.org you might have some luck speaking to the devs on there. Good luck, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: chombee [EMAIL PROTECTED] Date: Tue, 29 Apr 2008 00:38:48 To:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Compiz default Application Switcher (Alt+Tab) is difficult to use On Tue, 2008-04-29 at 00:20 +0100, chombee wrote: snip I took the liberty of assuming you meant to reply to the list and not just me. I would like to find out what if anything is happening among the compiz people about this issue and speak to them about, but I can't find out how. Their website is quite confusing (for one thing I don't know if I want compiz.org or compiz-fusion.org). I gave up easily, I'll try again. snip So I discovered that both compiz.org and compiz-fusion.org point to the forums at http://forum.compiz-fusion.org/. I couldn't find any mailing list or bug tracker. A search of the forum for application switcher finds that various people have complained about both of the issues with the application switcher in various threads, but it doesn't look like anything is being done about it. Ubuntu has been shipping with this (in my opinion) major usability regression for I believe a year now? And it's not the only one, the Show Desktop button is pretty bust in compiz too. I worry that there is no developer momentum to get these kind of usability issues in compiz fixed. I'm not sure there was anything useful I could do. Perhaps I could have started another thread, summed up the issues and how they should be fixed, and linked to all the other threads, my closed bug report, and this thread, but I would only have been repeating what has already been said. I'd like to point out that metacity's new compositor has a correct implementation of alt-tab with window previews. In general compiz has many bugs and usability regressions compared to metacity, but in my testing metacity's compositor is not as fast as compiz. Hopefully it will catch up and could potentially replace compiz, but I fear compiz is already too entrenched, it seems to be very popular. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Compiz default Application Switcher (Alt+Tab) is difficult to use
And at this point seems to have more community support, and a faster development cycle. Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: chombee [EMAIL PROTECTED] Date: Tue, 29 Apr 2008 00:38:48 To:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Compiz default Application Switcher (Alt+Tab) is difficult to use On Tue, 2008-04-29 at 00:20 +0100, chombee wrote: snip I took the liberty of assuming you meant to reply to the list and not just me. I would like to find out what if anything is happening among the compiz people about this issue and speak to them about, but I can't find out how. Their website is quite confusing (for one thing I don't know if I want compiz.org or compiz-fusion.org). I gave up easily, I'll try again. snip So I discovered that both compiz.org and compiz-fusion.org point to the forums at http://forum.compiz-fusion.org/. I couldn't find any mailing list or bug tracker. A search of the forum for application switcher finds that various people have complained about both of the issues with the application switcher in various threads, but it doesn't look like anything is being done about it. Ubuntu has been shipping with this (in my opinion) major usability regression for I believe a year now? And it's not the only one, the Show Desktop button is pretty bust in compiz too. I worry that there is no developer momentum to get these kind of usability issues in compiz fixed. I'm not sure there was anything useful I could do. Perhaps I could have started another thread, summed up the issues and how they should be fixed, and linked to all the other threads, my closed bug report, and this thread, but I would only have been repeating what has already been said. I'd like to point out that metacity's new compositor has a correct implementation of alt-tab with window previews. In general compiz has many bugs and usability regressions compared to metacity, but in my testing metacity's compositor is not as fast as compiz. Hopefully it will catch up and could potentially replace compiz, but I fear compiz is already too entrenched, it seems to be very popular. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
