Terrible response time when using Synergy on client side on Hardy
Hi all, I have used synergy to access multiple systems with a single master system. I am currently using two laptops: Server: Gutsy Client: Hardy When I try to access the client through the mouse of the server the system response is pretty bad. The mouse freezes often. I was using quicksynergy from my account. I invoked the command $ synergyc -f -1 --no-camp explicitly from the terminal without much luck. But when I gave the same command as a root it worked like a charm. I din't remember noticing any such problems with Feisty earlier so I reversed the laptops: Server: Hardy Client: Gutsy The response is a little slow but not so terrible. Again with the superuser account this is better. On Hardy this is intolerable. I believe this is to do with the priorities of the processes. Is there a way to fix it so that I can get a good response for a normal user. synergc should count as a I/O intensive process but I am not sure why it works fine when process has been created by root and not otherwise. Hardy is installed on a Thinkpad T61 while Gutsy is on a Sony VAIO VGN-240E both dual core with 64 bit versions of Ubuntu. Thanks in advance, Mayank -- 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 AT&T -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 AT&T -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
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 AT&T -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
This doesn't change the ideas of remote recovery ata ll, you simply need to use key-based authentication, which you listed in your first draft already. I also think it might be a good idea to check is SSH is running, and if not run it on an abnormal (higher) port. Also taking advantage of the reverse SSH tunnel will ease the NAT/Firewall issue. For that matter, the "newbie" system could allow SSH connections only from localhost (which would be the most secure process), leaving you only with the need to secure the "helpers" system/service. Thanks, Justin M. Wray Sent via BlackBerry by AT&T -Original Message- From: Andrew Sayers <[EMAIL PROTECTED]> Date: Wed, 07 May 2008 01:40:44 To:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier Based on this evidence, does anybody object to a bug report being filed against openssh-server, saying that password authentication should be disabled by default? Of course, that leaves all my ideas in serious trouble, but that's a secondary matter. - 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
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
Re: Suggestion to make remote recovery easier
On Tue, May 6, 2008 at 8:40 PM, Andrew Sayers <[EMAIL PROTECTED]> wrote: > Based on this evidence, does anybody object to a bug report being filed > against openssh-server, saying that password authentication should be > disabled by default? Of course, that leaves all my ideas in serious > trouble, but that's a secondary matter. > One intermediate take away from the study is that using a high non-standard port is often good enough (for now). Also, having denyhosts configured with a sync download threshold of 3 will block a high percentage (I think it said %75 or so) You have to remember that security is a game of escalation and even though people should try to stay ahead of the attackers, they often don't. Should Ubuntu packages force them to do things that they don't necessarily yet understand? I think that topic is a thread of its own if people want to go down that path. More closely to the thread at hand, a reasonable amount of security could be gained by using a non-standard port, a hard username/password, and/ or using SSH keys. Cheers, Todd -- 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
Based on this evidence, does anybody object to a bug report being filed against openssh-server, saying that password authentication should be disabled by default? Of course, that leaves all my ideas in serious trouble, but that's a secondary matter. - 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
Re: Suggestion to make remote recovery easier
On Tue, May 6, 2008 at 8:20 PM, Scott Kitterman <[EMAIL PROTECTED]> wrote: > On Tue, 06 May 2008 23:56:18 +0100 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 > > 7) Most end users have an extremely niave view of security. They want > "security", but understand very little about how changes to their systems > affect the security of their systems. Changes made cannot make systems > less secure. > > I'd invite you to look at the rate of ssh dictionary attacks on internet > exposed boxes and consider if any password based ssh solution is > appropriate. > There has been quite a bit of research on this topic at Clarkson University. see: http://monitor.sclab.clarkson.edu/thesis.doc and http://monitor.sclab.clarkson.edu/appendicies.doc Abstract: In its Top-20 Security Risks report for 2007, the SANS Institute called brute-force password guessing attacks against SSH, FTP and Telnet servers the most common form of attack to compromise servers facing the Internet.Another recent study also suggests that Linux systems may play an important role in the command and control systems for botnets. Defending against brute-force SSH attacks may therefore prove to be a key factor in the effort to disrupt these networks. We report on a study of brute-force SSH attacks observed on three very different networks: an Internet-connected small business network, a residential system with a DSL Internet connection, and a university campus network. The similarities observed in the methods used to attack these disparate systems are quite striking. The evidence suggests that many brute-force attacks are based on pre-compiled lists of usernames and passwords, which are widely shared. We were able to confirm the existence of one such pre-compiled list after it was discovered in a SSH attack toolkit captured in a related honeypot project. Analysis of the passwords used in actual malicious SSH traffic suggests that the common understanding of what constitutes a strong password may no longer be sufficient to protect systems from compromise. Study data are also used to evaluate the effectiveness of a variety of techniques designed to defend against these attacks. Cheers, Todd -- 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
On Tue, 06 May 2008 23:56:18 +0100 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 7) Most end users have an extremely niave view of security. They want "security", but understand very little about how changes to their systems affect the security of their systems. Changes made cannot make systems less secure. I'd invite you to look at the rate of ssh dictionary attacks on internet exposed boxes and consider if any password based ssh solution is appropriate. Scott K -- 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
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. Solving the three sub-problems individually allows for more flexibility, because then intermediate users can mix-and-match the parts that they're interested in. Creating, modifying, and deleting accounts is a standard problem, and I've already suggested ways to add the necessary bits into Ubuntu (specifying an authorised key when creating an account, etc.). Since I used the alternate install CD, I don't know whether the default Ubuntu installation gives you the option to set up extra user accounts after installing. If it does, I'd recommend adding a "technical friend" user account creation option. But since most people will click straight through the above option, it would be good if this was offered explicitly somewhere in the System menu, and if a program like friendly-recovery could offer the same functionality from the command line. If there's an interest in it, I would be happy to maintain some sort of "ssh-strategies" script/page that walks people through an increasingly complex decision tree, trying to set up an SSH connection. In order to work easily, there would probably have to be some sort of ssh-strategies-minimal package in the default install. I'd be even more happy if Canonical were willing to host a couple of very simple scripts at ubuntu.com to confirm the user's world-visible IP address and to reflect half a dozen SSH packets back to the address they came from. The former can't be done over HTTP because of the mess of transparent proxies on the net nowadays, and the latter should be safe so long as just enough packets to appear in the SSH log are sent, but not enough to try a password are sent. - 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
Re: Suggestion to make remote recovery easier
On Tue, May 06, 2008 at 06:39:25PM +0100, Andrew Sayers wrote: > I've now updated the page that Pedro kindly started at > https://wiki.ubuntu.com/Recovery/Remote - this includes all the ideas > I've got so far. This is my first Ubuntu development thing, so yes, any > help very much appreciated! Well then welcome aboard! :-) > Then we can add a page to the help wiki, describing how to create a user > for port-forwarding, how to create an SSH-only user, and how to make > that user an administrator. That would give intermediate users all the > tools they need to set up a permanent remote help relationship that they > can tune to their particular needs. One other thing to consider is configuring an external router for the ssh traffic, in case of routers that lock out ssh traffic. > Help with managing a system is an interesting use case, but I'm not sure > if we want to be targeting it with this particular solution. I agree > that sane defaults with powerful configuration is a good approach for > users that know what the configuration options mean, but newbies with a > broken system should be asked as few questions as possible (especially > when they're paying for a long-distance phone call). Also, I think > you're talking about an ongoing remote help relationship, rather than an > emergency one shot thing. It's occurred to me that most of my non-technical friends and family who use Linux, have a semi-formal relationship with their "tech guy" (usually me, but not always). I don't think this is unique to Linux - most of these people bugged me with Windows questions before converting (and indeed, a large part of their motivation to switch was me saying, "Hey, I'd like to help, but honestly my windows knowledge is diminishing since I no longer use it.") So I've wondered if things like remote restore / remote management could enable Ubuntu to expand further. I know I have friends and folks out of town I could move over to Linux if it were simpler to set them up for remote operations. > 1) Rather than create a "remote-recovery" user on the recovery machine, > why not just let the expert log in as root? Given all the other > security measures, it wouldn't be any less secure, and would avoid the > need to have a password kicking about. Hmm, this sounds dangerous. > 2) Experts that have just finished a remote recovery session are > probably the best people there are for providing high quality bug > reports. Possibly, and a good point, although I'm not sure any special handling for bug reporting is needed for these kinds of people. Bryce -- 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: Making apt-get powercut-proof
That's a pretty handy tool - would you be interested in an option to start the remote recovery that's being discussed in a nearby thread? Also, how would you feel if I suggested the options/dpkg script to the APT development team as the basis for an init script? I don't expect it would add more than a few seconds to boot time (or less if there's a lockfile that they can check for the existence of), and it would tackle the specific issue I had, where the problem presented as a missing home directory, and only turned out to be a package installation issue after much investigation. - Andrew Sayers -- 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
I've now updated the page that Pedro kindly started at https://wiki.ubuntu.com/Recovery/Remote - this includes all the ideas I've got so far. This is my first Ubuntu development thing, so yes, any help very much appreciated! You're quite right that the people you have to worry about aren't the ones that know nothing, but the ones that know just enough to be dangerous. In fact, given the desire for robustness (and the Robustness Principle in general), I think it would be best to design this facility based on the assumption that the user has been damaged their system as much as possible without actually disabling the remote-recovery script. That should encourage a sufficiently defencive design. Help with managing a system is an interesting use case, but I'm not sure if we want to be targeting it with this particular solution. I agree that sane defaults with powerful configuration is a good approach for users that know what the configuration options mean, but newbies with a broken system should be asked as few questions as possible (especially when they're paying for a long-distance phone call). Also, I think you're talking about an ongoing remote help relationship, rather than an emergency one shot thing. How about we break this off into a separate feature request: The "Add User" dialogue in "Users settings" (System->Administration->Users and Groups) should have the following extra options: * Disallow password logins * generate an SSH key, using either no passphrase, a randomly generated passphrase, the login password, or a specific passphrase. When the user account is added, the SSH public keys are given in a popup box * Add specified SSH public keys to .ssh/authorized_keys Then we can add a page to the help wiki, describing how to create a user for port-forwarding, how to create an SSH-only user, and how to make that user an administrator. That would give intermediate users all the tools they need to set up a permanent remote help relationship that they can tune to their particular needs. Given the above, I've left the iptables things more-or-less intact on the Remote Recovery page, since it's a good piece of robustness against newbies. Finally, two more ideas have occurred to me: 1) Rather than create a "remote-recovery" user on the recovery machine, why not just let the expert log in as root? Given all the other security measures, it wouldn't be any less secure, and would avoid the need to have a password kicking about. 2) Experts that have just finished a remote recovery session are probably the best people there are for providing high quality bug reports. Ubuntu already asks for unstructured feedback when installing a system, so it seems natural to give the same option to these people. Presumably we need to ask someone at Canonical about whether they'd be interested in this feedback? If so, who? - 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
Re: Making apt-get powercut-proof
Just by my feel of gut I'd guess that some unexperienced people who simply don't want to wait long might find it encouraging to just skip packages even if they are told that this might be normal. However if a package installation aborts (not like with scrollkeeper but simply fails), which is an evident sign of a problem, then being able to skip this item within update-manager or synaptic would be great I think. 2008/5/6 Andrew Sayers <[EMAIL PROTECTED]>: > Milosz Derezynski wrote: > > It could work if after the package is skipped apt recreates the > > dependency list; this might be bad to oversee though (especially without > > a GUI), however adding a printout a la "These packages were originally > > meant to be installed: $PACKAGES Since package $PACKAGE was removed > > after the update began, they are NOT going to be installed [Y/n]" where > > n would retry with the same package included again. One could even think > > of a skip-broken-packages option. Since non-installed packages remain in > > the dpkg/apt system as to-be-upgraded there is no real problem (if apt > > would additionally save the status then in update-manager they could be > > shown as unchecked with a hint that they failed to install). > > I don't think I'd want the actual apt-get command line to be > second-guessing me, so how about this for a feature suggestion (to > update-manager and to synaptic): > > If a package takes more than 60 seconds to install, force the "details" > window to open, and also present a dialogue box saying: > > $PACKAGE has taken more than a minute to install. This is normal for > some packages, but might be a sign of a problem. > > The following packages depend on $PACKAGE: $DEPENDENCIES > > [ Stop installing ] [ Skip this package ] [ Keep waiting ] > > Clicking "stop installing", obviously, stops the installation. The > package that failed is then highlighted in the main window. > > "Skip this package" kills the PID of the shell script that apt is > running. I'd have to check, but I think that apt does the right thing > in that situation. > > Clicking "keep waiting" sends the dialogue box away for 5 minutes (then > for 10 minutes, then for 15 minutes...) > >- 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: Making apt-get powercut-proof
De: [EMAIL PROTECTED] en nombre de Michael Vogt Enviado el: mar 06/05/2008 9:51 Para: Andrew Sayers CC: ubuntu-devel-discuss@lists.ubuntu.com Asunto: Re: Making apt-get powercut-proof >The new friendly recovery is also in my PPA at https://edge.launchpad.net/~mvo/+archive (for those curious to test). Can you explain more in https://wiki.ubuntu.com/Recovery ? I.e. how to install these packages ?. On the other hand, an interesting address for offline package update: http://offline.debian.net This could be use by update-manager for offline update. Regards. -- 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: Making apt-get powercut-proof
Hi,
On Mon, May 05, 2008 at 08:57:36PM +0100, Andrew Sayers wrote:
> A friend of mine was upgrading to Hardy, and (so far as we can tell)
> there was a power cut while it was halfway through, which left his
> system in a not-especially-useful state. I think the best solution is
> to have a /etc/init.d/{apt-get|dpkg} script that checks for
> half-finished installs, and restarts them if necessary. If so, which
> (or both) would be better, and is there anyone here that knows enough
> about the two to suggest a complete set of commands that need to be run?
> Also, is this something we should be doing in an Ubuntu-specific way
> (e.g. from X), or should I take this idea to Debian?
I added a dpkg/apt recovery to the friendly-recovery package in
intrepid. When booting into recovery mode it will have a "dpkg -
Repair packages" menu item that will do the required steps. I plan to
also extend update-manager so that it is available there.
The new friendly recovery is also in my PPA at
https://edge.launchpad.net/~mvo/+archive
(for those curious to test).
Cheers,
Michael
--
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
De: Andrew Sayers Enviado el: lun 05/05/2008 21:26 Para: ubuntu-devel-discuss Asunto: Suggestion to make remote recovery easier >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: Added to https://wiki.ubuntu.com/RemoteRecovery . Good work. You could propose it to Brainstorm and to Launchpad to make it a specification. The more secure way to work is in local phone call (modem). Regards. -- 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: Making apt-get powercut-proof
De: Bryce Harrington
Enviado el: lun 05/05/2008 22:51
Para: Andrew Sayers
CC: ubuntu-devel-discuss
Asunto: Re: Making apt-get powercut-proof
On Mon, May 05, 2008 at 08:57:36PM +0100, Andrew Sayers wrote:
> A friend of mine was upgrading to Hardy, and (so far as we can tell)
> there was a power cut while it was halfway through, which left his
> system in a not-especially-useful state. I think the best solution is
> to have a /etc/init.d/{apt-get|dpkg} script that checks for
> half-finished installs, and restarts them if necessary. If so, which
> (or both) would be better, and is there anyone here that knows enough
> about the two to suggest a complete set of commands that need to be run?
> Also, is this something we should be doing in an Ubuntu-specific way
> (e.g. from X), or should I take this idea to Debian?
I think this is an Ubuntu specific way, because wants to be as easy (or even,
more easy) than other operating systems.
And this really would be powercut-proof box, not only related to apt-get.
One could include an entry in the launchpad o brainstorm.
Regards.
--
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: Developemnt and use - Training manual
Hi, On Mon, May 5, 2008 at 9:02 AM, Billy Cina <[EMAIL PROTECTED]> wrote: > Ubuntu is a free distribution and will always continue to be free. > However, this does not mean that every service provided to support Ubuntu or > its further expansion must also be free. Both the Ubuntu community and > Canonical have invested a lot of time and money in developing this course, > it is therefor reasonable for: a. the community to be able to use the > material (freely) to further spread the work of Ubuntu and grow the user > base, and b. for Canonical to determine who should be seeking a profit out > of its investment. I'm also uncomfortable with this argument. As others have pointed out, the same reasoning could be applied to the Ubuntu distribution itself. There may be a better distinction to be made here between work done by the Ubuntu community, and Canonical's profit-making business. When the training manual was first released I was disappointed not only that it had been released under a non-free licence, but also because I looked on the mailing list and found no public discussion whatsoever of the licence to be chosen. The non-free licence has meant that it is completely impossible for the project to share content or work with the Ubuntu documentation project (in either direction), because of the incompatibility of free documentation with non-free documentation. I think the reason for my disappointment was that the training project had been promoted as a community project. I understand that Canonical is investing money in order to produce this material, and I don't have a problem with Canonical seeking to recoup money from that investment, but if a non-free licence is required to protect that, I think the emphasis placed on community involvement in the project is misplaced. The Ubuntu community has an obligation to its philosophy to produce free material. I think my view remains the same even though I recognise that community members might easily wish to contribute to the project voluntarily, in the knowledge that the project is producing non-free material. I think the Ubuntu community has a duty to ensure that each of the sub-projects that it is being associated with are compatible with its philosophy. Having said that, it's obviously a difficult question, and I think that public discussion should have taken place over this right at the start of the project. -- Matthew East http://www.mdke.org gnupg pub 1024D/0E6B06FF -- 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
