Re: Suggestion to make remote recovery easier
Wow, you guys are going at this problem with a ferocious intent. We are already working on a remote support tool, a lot of what you've been talking about we have already talked about and built. So far it's not finished and much work is needed in peer review so if you can lend your time to looking at: https://launchpad.net/locoremotesupport/ We would be most grateful. Our plans are remote support using a combination of reverse tunnel ssh and jabber chat services. Do let me know if you start another project (coding) or if you figure out the ideal way of organising ssh. Best Regards, Martin Owens, Ubuntu-US-MA leader 2008/5/8 John McCabe-Dansted <[EMAIL PROTECTED]>: > On Wed, May 7, 2008 at 6:56 AM, Andrew Sayers > <[EMAIL PROTECTED]> wrote: > > > > > 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 thread. > > > -- 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 Wed, May 7, 2008 at 6:56 AM, Andrew Sayers < [EMAIL PROTECTED]> wrote: > 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 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. Perhaps we could use reverse tunnels. The end user could reverse tunnel into some server trusted by the admin. See e.g. http://gentoo-wiki.com/TIP_SSH_Reverse_Tunnel Alternatively, perhaps we could do something like: mkfifo sshout mkfifo sshin ssh [EMAIL PROTECTED] < sshin > sshout & bash < sshout > sshin & -- John C. McCabe-Dansted PhD Student University of Western Australia -- 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 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 AT&T -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: 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
dpkg error: unable to make backup link of '...'
Hi, I have been getting this dpkg error: unable to make backup link of '...'. I have been posting my question on various forum and I still cant' resolve it. dpkg: error processing /var/cache/apt/archives/xfonts-encodings_1%3a1.0.2-3_all.deb (--unpack): unable to make backup link of `./usr/share/fonts/X11/encodings/large/big5hkscs-0.enc.gz' before installing new version: Operation not permitted dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/python-gnome2-extras_2.19.1-0ubuntu7_i386.deb /var/cache/apt/archives/xfonts-encodings_1%3a1.0.2-3_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) The closest thing I can find in google is this bug report. https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/93320 But i don't know how to solve my problem. I appreciate if anyone can help. -- 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: firefox and bad ssl certificates
On Wednesday 07 May 2008 22:14, Mackenzie Morgan wrote: > On Wed, 2008-05-07 at 22:05 -0400, Scott Kitterman wrote: > > On Wednesday 07 May 2008 20:34, HggdH wrote: > > > 100% with you. But it all has to start with education, not just forcing > > > a new feature down the user's throat. For most casual users, this > > > education is -- from my own experience with casual and theoretically > > > technical users -- not easy. And I do understand X509 & friends. > > > > > > On this point, I wonder if we are just making it a bit harder what most > > > users have been doing for ever. All we will get is grumbling, *unless* > > > we also provide clear, short, nice, reasonable, explanations. > > > > > > Ah well. > > > > While we're on this topic, I think point number 5 in this essay bears > > re-reading: > > > > http://www.ranum.com/security/computer_security/editorials/dumb/ > > > > Scott K > > But point #4 says "hacking is cool" is dumb...though there'd be no Linux > kernel or GNU tools without hackers. Different definition of hackers. 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: firefox and bad ssl certificates
On Wed, 2008-05-07 at 22:05 -0400, Scott Kitterman wrote: > On Wednesday 07 May 2008 20:34, HggdH wrote: > > > 100% with you. But it all has to start with education, not just forcing > > a new feature down the user's throat. For most casual users, this > > education is -- from my own experience with casual and theoretically > > technical users -- not easy. And I do understand X509 & friends. > > > > On this point, I wonder if we are just making it a bit harder what most > > users have been doing for ever. All we will get is grumbling, *unless* > > we also provide clear, short, nice, reasonable, explanations. > > > > Ah well. > > > > While we're on this topic, I think point number 5 in this essay bears > re-reading: > > http://www.ranum.com/security/computer_security/editorials/dumb/ > > Scott K But point #4 says "hacking is cool" is dumb...though there'd be no Linux kernel or GNU tools without hackers. -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo signature.asc Description: This is a digitally signed message part -- 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: firefox and bad ssl certificates
On Wednesday 07 May 2008 20:34, HggdH wrote: > 100% with you. But it all has to start with education, not just forcing > a new feature down the user's throat. For most casual users, this > education is -- from my own experience with casual and theoretically > technical users -- not easy. And I do understand X509 & friends. > > On this point, I wonder if we are just making it a bit harder what most > users have been doing for ever. All we will get is grumbling, *unless* > we also provide clear, short, nice, reasonable, explanations. > > Ah well. > While we're on this topic, I think point number 5 in this essay bears re-reading: http://www.ranum.com/security/computer_security/editorials/dumb/ 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: Some fundamental usability issues
On Thu, 2008-05-08 at 02:24 +0100, chombee wrote: > * The user should never have to press Save. There should not be any save > buttons anywhere on the computer. Saving is something the computer can > do automatically all the time, the user never needs to know. Save > buttons were introduced back when saving a file to disk required the > computer to freeze for several seconds. They are no longer needed, and > haven't been for some time! The GTK text editor Scribes is one program > that handles all your saving for you. Any others? Don't you ever open up gedit or whatever and use it to paste a bunch of stuff so you can refer to it all in *one* window instead of having to switch tabs a bunch? Your idea would mean going around having to delete a bunch of temporary files that were autogenerated. > * This whole business of highlighting some text then pressing a button, > whether it's paste or just a normal key, and having the highlighted text > replaced, should be thrown out. This seems to be how it works in every > text editor, but I think it's rarely what the user wants to do, and in > the rare cases where you do want to do that you can stand one extra key > press: highlight, delete, then paste or type in the replacement. **The > user's content is sacred** and it should never be deleted unless the > user explicitly selects it and presses delete. There's no single keyboard button that does that. There's middle-click-to-paste, but given that most mice have 2 buttons or 2 buttons and a scroll wheel, this requires a fairly deliberate attempt at getting the left and right buttons to go down simultaneously. -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo signature.asc Description: This is a digitally signed message part -- 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: firefox and bad ssl certificates
On Wed, 7 May 2008 17:36:54 -0600 Neal McBurnett <[EMAIL PROTECTED]> wrote: >On Thu, May 08, 2008 at 12:45:46AM +0200, Martin Pitt wrote: >> Peio Ziarsolo [2008-05-07 13:03 +0200]: >> > But for power user that know the significance of a bad certificate it's >> > annoniying add exceptions (this morning I have to add 3 esceptions). >> >> This doesn't have anything to do with power users/n00bs. An invalid >> SSL certificate isn't any better or worse depending on the type of >> user. If a site sets up SSL with an invalid certificate, then this >> buys the user nothing but a false sense of security. >> >> The proper approach to this IMHO is to make adding exceptions in all >> web browsers (especially IE) as hard and explicit as in Firefox 3. >> This would perhaps force site admins to get a grip and stop ignoring >> broken SSL certs, once they get a flood of complaints. >> >> > Is there any key to toogle off this new feature? >> >> I *so much* hope that there isn't. People should really start to >> understand that this is a SERIOUS error and shouldn't at all be >> considered 'normal'. > >Invalid certs are one thing. But doesn't this also affect self-signed >certs? > >Self-signed certs are appropriate for many use cases in which the goal >is primarily encryption (e.g. to protect data flowing back from the >server to the user), rather than e.g. protecting bank accounts by >authenticating the server to the user. E.g. connecting to a local >ebox management port, or a small community wiki. > >In many low-security situations, this change pushes server operators >into buying pricey certs from certificate vendors who often offer >little or no meaningful vetting and accept zero liability. > >This stuff is complicated, involves politics, and can't be painted >with such a broad brush. Education is a big part of it, like with most >security-related issues. > >The current warnings are confusing, and are being improved. Let's try >to see to it that they communicate as well as possible. Otherwise too >many grass-roots sites will just go back to asking folks to enter >passwords over unencrypted connections, or users will get used to >bypassing yet another set of dialogs and phishing will continue >scarcely abated. > >E.g. how hard is it for folks to buy in to their own web of trust and >get e.g. all CACert certs accepted? > > http://cacert.org > I think you are correct. This "improved security" may well have the opposite result. Additionally, a valid SSL cert for a particular domain does nothing to solve phishing based on near-match (cousin) domains. Unlike email, exact domain forgery is not the major problem. If I own paypa1.com, I can get a valid SSL cert for it too. SSL (aka TLS) is about securing data from external observation. Trying to overlaod it with a hierarchical CA cert system does not provide substantial endpoint authentication. At best it helps against exact domain spoofing (via DNS attacks). At worst it encreases user risk due a false sense of security. In my experience these kinds of U/I hurdles just annoy and desensitize the user and do not provide any real security. 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
Some fundamental usability issues
Warning: this is a rant. But hopefully we can discuss any developments in Ubuntu in the direction of what I'm talking about. I hope this was the best place to post this. * * * I have little hope that much can happen about this because it would be such a major overhaul, but... my friend was just writing a blog post in wordpress 2.5, in the epiphany browser, in ubuntu 8.04. She wrote for about an hour, was very happy with it, then accidentally highlighted the entire text and pasted the contents of the clipboard in its place. I immediately told her to stop and press Ctrl+Z. Unfortunately there seems to be a bug, that only occurs with wordpress, and then only if you are using Epiphany, that means Undo does not work. (I have reported it.) Wordpress.com even autosaves your work, but it apparently auto-saved again after she had destroyed the content, and it does not keep a history of autosaves, only the most recent one. Pretty unlucky all in all. But there is so much fundamentally wrong usability cruft going on here. This sort of incident should not be possible. * The user should never have to press Save. There should not be any save buttons anywhere on the computer. Saving is something the computer can do automatically all the time, the user never needs to know. Save buttons were introduced back when saving a file to disk required the computer to freeze for several seconds. They are no longer needed, and haven't been for some time! The GTK text editor Scribes is one program that handles all your saving for you. Any others? * This whole business of highlighting some text then pressing a button, whether it's paste or just a normal key, and having the highlighted text replaced, should be thrown out. This seems to be how it works in every text editor, but I think it's rarely what the user wants to do, and in the rare cases where you do want to do that you can stand one extra key press: highlight, delete, then paste or type in the replacement. **The user's content is sacred** and it should never be deleted unless the user explicitly selects it and presses delete. * The whole paradigm of embedding semi-functional text editors in web browsers. I mean semi-functional when compared to the system's stand-alone text editor application. For how many years have people been typing out emails into web browsers, pressing Send, getting a server error, and losing their work? There must be a better way. The web browser should just integrate with the system's text editor so that text is not lost when the browser or some Internet server messes up. With these new flashy web 2.0 text editors we're seeing now that do things like autosave, like ironically the wordpress editor, this particular problem might be alleviated. * The system should automatically keep a history of the users files! We have masses of hard drive space now. At least for text files and office documents, surely this is doable! With my own work, I keep it all in a git repository which I commit to every few hours. So no matter what I do, even if I manage to completely delete a file, I can still get it back. Even if I delete the repository itself *and* the working copy, or destroy my computer, I still will not lose my work as I have it distributed on several machines which are all kept in sync. Using git is ridiculously difficult and technical by the standards of most normal users, but I see no reason why a versioning system could not be built in to the OS or the desktop environment and function completely without user interaction until the user wants to recover a previous version of something. And that can be made very simple and easy to do. Imagine it being virtually impossible to lose any of your work, ever. Isn't that a killer feature? Why hasn't this happened? -- 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
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: 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 remote_help.sh Description: application/shellscript -1 echo problem 3 /bin/false 2 echo foo 2 echo '2' 3 echo bar -- 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: firefox and bad ssl certificates
On Thu, 2008-05-08 at 00:45 +0200, Martin Pitt wrote: > This doesn't have anything to do with power users/n00bs. An invalid > SSL certificate isn't any better or worse depending on the type of > user. If a site sets up SSL with an invalid certificate, then this > buys the user nothing but a false sense of security. Sorry. What *is* an invalid certificate? A certificate that does not carry the fully-qualified host name in its Common Name? If this is your view, I humbly beg to differ. An invalid certificate is a certificate that is outside its timeframe (not valid before/after), or that does not verify against the root (all the way through the chain), or that is used outside its specified capabilities (but *this* one is oh so very tricky...), for example. But not matching the FQHN does *NOT* make a certificate invalid. At all. Even more because there is no standard requiring it. Well, there is the common use, but it is common use also for most users to accept any certificate received on the wire. Common use does not cut it. > The proper approach to this IMHO is to make adding exceptions in all > web browsers (especially IE) as hard and explicit as in Firefox 3. > This would perhaps force site admins to get a grip and stop ignoring > broken SSL certs, once they get a flood of complaints. I fully agree. Nevertheless, we cannot be more royal than the king. I myself had one case where a generic certificate installed by a software vendor (so that only HTTPS would be feasible from the beginning) was flatly and utterly refused by epiphany-browser (wrong usage). Firefox, at least swallowed it after I added the exception. Here the point is: we do not even agree with ourselves how to deal with certificates, and we expect users to be happy? > > Is there any key to toogle off this new feature? > > I *so much* hope that there isn't. People should really start to > understand that this is a SERIOUS error and shouldn't at all be > considered 'normal'. 100% with you. But it all has to start with education, not just forcing a new feature down the user's throat. For most casual users, this education is -- from my own experience with casual and theoretically technical users -- not easy. And I do understand X509 & friends. On this point, I wonder if we are just making it a bit harder what most users have been doing for ever. All we will get is grumbling, *unless* we also provide clear, short, nice, reasonable, explanations. Ah well. ..hggdh.. signature.asc Description: This is a digitally signed message part -- 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: firefox and bad ssl certificates
On Wed, 2008-05-07 at 17:36 -0600, Neal McBurnett wrote: > E.g. how hard is it for folks to buy in to their own web of trust and > get e.g. all CACert certs accepted? > > http://cacert.org > > Neal McBurnett http://mcburnett.org/neal/ As far as I am aware, Ubuntu includes CACert in Firefox by default. It's provided by the ca-certificates package. -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo signature.asc Description: This is a digitally signed message part -- 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: firefox and bad ssl certificates
On Thu, May 08, 2008 at 12:45:46AM +0200, Martin Pitt wrote: > Peio Ziarsolo [2008-05-07 13:03 +0200]: > > But for power user that know the significance of a bad certificate it's > > annoniying add exceptions (this morning I have to add 3 esceptions). > > This doesn't have anything to do with power users/n00bs. An invalid > SSL certificate isn't any better or worse depending on the type of > user. If a site sets up SSL with an invalid certificate, then this > buys the user nothing but a false sense of security. > > The proper approach to this IMHO is to make adding exceptions in all > web browsers (especially IE) as hard and explicit as in Firefox 3. > This would perhaps force site admins to get a grip and stop ignoring > broken SSL certs, once they get a flood of complaints. > > > Is there any key to toogle off this new feature? > > I *so much* hope that there isn't. People should really start to > understand that this is a SERIOUS error and shouldn't at all be > considered 'normal'. Invalid certs are one thing. But doesn't this also affect self-signed certs? Self-signed certs are appropriate for many use cases in which the goal is primarily encryption (e.g. to protect data flowing back from the server to the user), rather than e.g. protecting bank accounts by authenticating the server to the user. E.g. connecting to a local ebox management port, or a small community wiki. In many low-security situations, this change pushes server operators into buying pricey certs from certificate vendors who often offer little or no meaningful vetting and accept zero liability. This stuff is complicated, involves politics, and can't be painted with such a broad brush. Education is a big part of it, like with most security-related issues. The current warnings are confusing, and are being improved. Let's try to see to it that they communicate as well as possible. Otherwise too many grass-roots sites will just go back to asking folks to enter passwords over unencrypted connections, or users will get used to bypassing yet another set of dialogs and phishing will continue scarcely abated. E.g. how hard is it for folks to buy in to their own web of trust and get e.g. all CACert certs accepted? http://cacert.org Neal McBurnett http://mcburnett.org/neal/ signature.asc Description: Digital signature -- 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: firefox and bad ssl certificates
Peio Ziarsolo [2008-05-07 13:03 +0200]: > But for power user that know the significance of a bad certificate it's > annoniying add exceptions (this morning I have to add 3 esceptions). This doesn't have anything to do with power users/n00bs. An invalid SSL certificate isn't any better or worse depending on the type of user. If a site sets up SSL with an invalid certificate, then this buys the user nothing but a false sense of security. The proper approach to this IMHO is to make adding exceptions in all web browsers (especially IE) as hard and explicit as in Firefox 3. This would perhaps force site admins to get a grip and stop ignoring broken SSL certs, once they get a flood of complaints. > Is there any key to toogle off this new feature? I *so much* hope that there isn't. People should really start to understand that this is a SERIOUS error and shouldn't at all be considered 'normal'. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- 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 (Matthew East)
Indeed the training manual is a non-commercial license, but why not make your own: The site https://help.ubuntu.com/, if you look at the https://help.ubuntu.com/8.04/newtoubuntu/C/legal.html indicates that this site is covered under the creative commons license; as is the https://help.ubuntu.com/community/ site at https://help.ubuntu.com/community/License. To me this means that as long as you keep the attribution in "your" teaching materials, there is no reason why you cannot use them. You are charging for your time/rent/computer lease/paper cost/admin cost and not the cost of the documentation itself. The email they(canonical) sent to contributors (https://wiki.ubuntu.com/WikiLicensing/Email) indicates a CC-by-SA license. There is absolutely no reason why you cannot take and reformat the documentation in a more usable form for training purposes as long as you maintain the CCbySA license, that is keeping the attribuions and potentially you may be required to publish your work at some point. As far as charging for training goes, there is nothing stopping you from doing that, just don't charge for the book. ie Blaise Allyens's Ubuntu Training Manual included free with the course. If you want to charge $100 a head or 2500 a head, that's the economics of training today. The same applies to training your employees. Where you may get into trouble is if you took someone else's training manual and used it to teach, as you may be breaching their copywrite, or other license. Regards, Glen Merrick -- 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: Four crashes, no apport actions
Le mercredi 07 mai 2008 à 18:00 +0200, Martin Pitt a écrit : > Hi, > > Milan Bouchet-Valat [2008-05-07 17:41 +0200]: > > Why is it disabled? > > Because > > (1) we have our hands full with fixing the development release and > want to concentrate on it > > (2) we should already know about the top crashers in stable releases, > and the ones which just occur randomly or very seldomly are not a > good target for stable updates anyway > > (3) we want to avoid people filing bugs and dozens of duplicates in > vain > > (4) automatic bug reports are always a potential privacy issue, which > is more concerning for stable users. > > > I find it very useful to debug for advanced users > > instead of getting gdb traces. Is there a way to manually activate it? > > Sure, you can turn it on in /etc/default/apport. OK, thanks for the info, I had not managed to understand why apport did sometimes start and sometimes not. But it's definitely a great tool when debugging. And I guess this can help when triagin bugs: we can simply tell the user to activate apport for the time he gets an automatic trace. -- 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 AT&T -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 AT&T -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 AT&T -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listin
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 AT&T -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 AT&T -- 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
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 AT&T -- 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 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 AT&T -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 pip
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) A non-interactive mechanism for swapping keys > > Adding only: > > 7) Custom command > > This is the exact sort of options I think should be avaliable in such a > solution. Allowing the "helpless user" pick when running the recovery > command. > > The best connection solution is a reverse connection to the helpless user, > this bypasses the NAT/Firewall issues. Ssh allows tunnleing, so when > possible we should use this (see above). > > Else we may want to look into `rrs` (remote reverse shell). > > Thanks, > Justin M. Wray > > Sent via BlackBerry by AT&T -- 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
Forwarding to the list... Thanks, Justin M. Wray Sent via BlackBerry by AT&T -Original Message- From: "Justin M. Wray" <[EMAIL PROTECTED]> Date: Wed, 7 May 2008 16:55:46 To:"Andrew Sayers" <[EMAIL PROTECTED]> Subject: Re: Suggestion to make remote recovery easier 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) A non-interactive mechanism for swapping keys Adding only: 7) Custom command This is the exact sort of options I think should be avaliable in such a solution. Allowing the "helpless user" pick when running the recovery command. The best connection solution is a reverse connection to the helpless user, this bypasses the NAT/Firewall issues. Ssh allows tunnleing, so when possible we should use this (see above). Else we may want to look into `rrs` (remote reverse shell). Thanks, Justin M. Wray Sent via BlackBerry by AT&T -Original Message- From: Andrew Sayers <[EMAIL PROTECTED]> Date: Wed, 07 May 2008 17:38:05 To:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier On the other hand, I'm wrong about that :) I've just discovered a package called socat, which is an extremely general command line tool for creating connections between things - more so even than netcat. It's in Universe, so it's presumably not that much of an ask to have it upgraded to main. I think we can create a general solution using socat. In the catastrpohic case, this would work if only socat and a shell script were still working (instead of ssh and a shell script). Let's formulate the problem this way: We need to create a bidirectional, secure method of communication between two computers. Some of the ways to set this up include: 1) Helpee connects to helper 2) Helper connects to helpee 3) Helpee and helper both connect to some shared proxy server Each of these can be done over IPv4 or IPv6, over the public Internet or a private connection (such as a modem). Once the connection is made, we need to start up an arbitrary interface using that channel. Possible interfaces include: 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 We can implement this using a collection of interface modules that request a particular type of connection from socat, and a collection of socat modules that deliver that connection over whichever protocol has been configured. Users can then add extra socat modules to handle their own esoteric situations. Does this seem workable? - 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: Four crashes, no apport actions
Le mercredi 07 mai 2008 à 18:00 +0200, Martin Pitt a écrit : > Hi, > > Milan Bouchet-Valat [2008-05-07 17:41 +0200]: > > Why is it disabled? > > Because hi, apport also uses quite some ressources which makes your system slow and make impossible to restart the corresponding application while it's working which can be a bad user experience Sebastien Bacher -- 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 the other hand, I'm wrong about that :) I've just discovered a package called socat, which is an extremely general command line tool for creating connections between things - more so even than netcat. It's in Universe, so it's presumably not that much of an ask to have it upgraded to main. I think we can create a general solution using socat. In the catastrpohic case, this would work if only socat and a shell script were still working (instead of ssh and a shell script). Let's formulate the problem this way: We need to create a bidirectional, secure method of communication between two computers. Some of the ways to set this up include: 1) Helpee connects to helper 2) Helper connects to helpee 3) Helpee and helper both connect to some shared proxy server Each of these can be done over IPv4 or IPv6, over the public Internet or a private connection (such as a modem). Once the connection is made, we need to start up an arbitrary interface using that channel. Possible interfaces include: 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 We can implement this using a collection of interface modules that request a particular type of connection from socat, and a collection of socat modules that deliver that connection over whichever protocol has been configured. Users can then add extra socat modules to handle their own esoteric situations. Does this seem workable? - 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: Four crashes, no apport actions
Hi, Milan Bouchet-Valat [2008-05-07 17:41 +0200]: > Why is it disabled? Because (1) we have our hands full with fixing the development release and want to concentrate on it (2) we should already know about the top crashers in stable releases, and the ones which just occur randomly or very seldomly are not a good target for stable updates anyway (3) we want to avoid people filing bugs and dozens of duplicates in vain (4) automatic bug reports are always a potential privacy issue, which is more concerning for stable users. > I find it very useful to debug for advanced users > instead of getting gdb traces. Is there a way to manually activate it? Sure, you can turn it on in /etc/default/apport. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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: Four crashes, no apport actions
Le mercredi 07 mai 2008 à 14:36 +0200, Stéphane Graber a écrit : > Apport is only used during development, it's turned off in final release. Why is it disabled? I find it very useful to debug for advanced users instead of getting gdb traces. Is there a way to manually activate it? -- 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: Four crashes, no apport actions
On Wed, May 07, 2008 at 08:41:16AM -0400, Mackenzie Morgan wrote: > On Wed, 2008-05-07 at 14:36 +0200, Stéphane Graber wrote: > > > > Apport is only used during development, it's turned off in final release. > > > > Stéphane > > I got 2 apport "omg something crashed, wanna report it?" popups today. Were these somethings python applications? Apport is still currently reporting python crashes. -- Brian Murray @ubuntu.com signature.asc Description: Digital signature -- 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
Justin, I agree that a single solution would be best, but I can't see how to make it work in the case of a system that's mostly broken. However, it looks like it's going to be an evidentiary question - either we can make it work or we can't. How would you feel about the following working arrangement: I'll rewrite my "remote recovery" blueprint based on ideas discussed here, focussing solely on the worst case; you write up a "remote help" blueprint focussing on the common case. Then we'll liberally criticque/merge/steal ideas and see where that goes. If we wind up with a single blueprint, great! If not, we'll have a good solution for the general case and an ugly solution that's just usable enough to bootstrap into the general case. In the spirit of working towards the middle then... I agree that VNC would be better in the common case. In fact, using VNC leaves the door open to someday expanding the solution to Windows-using friends, although that's definitely a version 2 idea. If we agree that passwords are best in the case of an emergency phone call from someone with no prior relationship, I think we should use keys everywhere else, but leave key exchange up to users. I agree that web/e-mail is better for people who aren't that paranoid, but those that are more paranoid will want the freedom to use whatever mechanism they trust. Showing the SSH session to the user in the recovery case is a very good idea, and should be fairly simple to implement. Some sort of chat session is also a good idea, so long as we can implement it so that two people aren't trying to type on the same command line at the same time. That should just involve putting chat and commands in two separate ttys. Another use case we need to think about is broken video cards/monitors/etc. that make it impossible for the non-technical friend to use their computer at all. This suggests that the expert should be able to log in by default, rather than having access only granted on request. - 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
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 AT&T -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
Re: firefox and bad ssl certificates
On Wed, May 07, 2008 at 10:57:24AM +0200, Alexander Sack wrote: > > In next firefox update the page will change a bit so users don't > confuse it with ordinary error page anymore. http://people.ubuntu.com/~asac/screenshots/bad_cert.png http://people.ubuntu.com/~asac/screenshots/bad_cert2.png - Alexander -- 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
(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 the phone. My public RSA key is 200 characters, while my DSA key is 580. Speaking 1 character per second, it would take more than 3 minutes to type out an RSA key. Passwords strike me as the only practical solution for remote recovery, but I've asked the SSH team whether they would disable password authentication in the default configuration. Their opinion is the one that matters, so I'll work around them in this specific case if necessary. I'd say it's best to wait for the SSH team to reply before making decisions about remote help. The question was posted here: https://answers.launchpad.net/ubuntu/+source/openssh/+question/32326 Given all of the above, here's a rough sketch for my new remote recovery proposal: The expert tells the friend a newly-generated one-time random password that the friend can use to SSH into a chrooted jail. The jail contains two pipes: shell_in and shell_out. A superuser shell is started on the recovery machine, and all input/output to it is routed over the SSH connection and through the pipes on the expert's machine. The expert can then access a root shell on the recovery machine by doing the following on the expert's machine: cat ~remote-recovery/shell_out & cat > ~remote-recovery/shell_in This "reverse login" is definitely not great for the recovery machine's security, so it should only be used in emergencies. However, it seems to me that it should be extremely robust in the face of breakage on the recovery machine. Going back to a point I made earlier, this isn't an everything-proof solution. For example, it's no use if the expert's ISP is running a NAT that the expert can't control (as my ISP seems to be threatening to do). However, that sort of thing strikes me as a problem best left for version 2, when we start to see what the actual problems are in the real world. - 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: Four crashes, no apport actions
On Wed, 2008-05-07 at 14:36 +0200, Stéphane Graber wrote: > > Apport is only used during development, it's turned off in final release. > > Stéphane I got 2 apport "omg something crashed, wanna report it?" popups today. -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo signature.asc Description: This is a digitally signed message part -- 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: Four crashes, no apport actions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Novin wrote: > Hello > > I just now had four crashes. First was emerald. Noticed that my borders > was missing. Manually restarted it via terminal with 'emerald --replace > &'. It crashed again. Started it a third time and then it worked. > Noticed segfault in syslog. > > Second was Evolution. I got a popup telling me "The Evolution memo has > quit unexpectedly. Your memos will not be available until Evolution is > restarted.". This caused some kind of problem for the desktop because I > could not click on anything. I eventually found out that I could use the > keyboard so I was able to use the keyboard to OK the popup and shutdown > Evolution. Then it was back to normal again. > > Third crash just after was Firefox. Started it, entered a location and > it just disappeared while the page was loading. > > Fourth was Seahorse. Synced my keys and pgp.mit.edu wasn't responding. > This caused Seahorse to crash and I could see a segfault in syslog. > > On neither of these four crashes apport kicked in. Why is that? > > Rgds > > Apport is only used during development, it's turned off in final release. Stéphane -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIIaJXjxyfqkjBhuwRAsGnAJ9KAZz2HjwGNWz9MvFQQoYjJybjIgCfWLJW zuxcwah5oAwfBc3uEsc1SXo= =UJp1 -END PGP SIGNATURE- -- 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
Four crashes, no apport actions
Hello I just now had four crashes. First was emerald. Noticed that my borders was missing. Manually restarted it via terminal with 'emerald --replace &'. It crashed again. Started it a third time and then it worked. Noticed segfault in syslog. Second was Evolution. I got a popup telling me "The Evolution memo has quit unexpectedly. Your memos will not be available until Evolution is restarted.". This caused some kind of problem for the desktop because I could not click on anything. I eventually found out that I could use the keyboard so I was able to use the keyboard to OK the popup and shutdown Evolution. Then it was back to normal again. Third crash just after was Firefox. Started it, entered a location and it just disappeared while the page was loading. Fourth was Seahorse. Synced my keys and pgp.mit.edu wasn't responding. This caused Seahorse to crash and I could see a segfault in syslog. On neither of these four crashes apport kicked in. Why is that? Rgds -- 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: firefox and bad ssl certificates
Jatorrizko mezua: az., 2008-05-07 10:57 +0200, egilea: Alexander Sack > On Wed, May 07, 2008 at 10:31:19AM +0200, Peio Ziarsolo wrote: > > Hello everybody, > > I have found different behaviours between firefox 2 and firefox3 when > > they detect a bad ssl certificate. > > Firefox 2, when detects the bad certificate warms you about it and give > > you the choise to carry on. > > Firefox 3, when detects the bad certificates, it show you a error page > > and doesn't allow you to look at it. > > > > I would like to know before report like a bug if this is a new security > > feature or if it is just a bug. It's annoniying not be able to look at a > > lot of web pages. > > This is a new security feature. The idea is to make users think and > understand about what they are doing by replacing the useless > click-through dialog by something that users actually has to read. > But for power user that know the significance of a bad certificate it's annoniying add exceptions (this morning I have to add 3 esceptions). Is there any key to toogle off this new feature? It'd be great if you could choose beetwen the actual method or a warning in the address bar, for example paintin it in red. Thanks for the soon answer. > If you look closely at the error page you are suggested to "add an > exception ..."; if you follow that link you should be able to get the > certificate and grand temporary/permanent exception for it. > > In next firefox update the page will change a bit so users don't > confuse it with ordinary error page anymore. > > > - Alexander > > -- “Es imposible que una persona aprenda lo que cree que ya sabe.” Epicteto -- 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: firefox and bad ssl certificates
On Wed, May 07, 2008 at 10:31:19AM +0200, Peio Ziarsolo wrote: > Hello everybody, > I have found different behaviours between firefox 2 and firefox3 when > they detect a bad ssl certificate. > Firefox 2, when detects the bad certificate warms you about it and give > you the choise to carry on. > Firefox 3, when detects the bad certificates, it show you a error page > and doesn't allow you to look at it. > > I would like to know before report like a bug if this is a new security > feature or if it is just a bug. It's annoniying not be able to look at a > lot of web pages. This is a new security feature. The idea is to make users think and understand about what they are doing by replacing the useless click-through dialog by something that users actually has to read. If you look closely at the error page you are suggested to "add an exception ..."; if you follow that link you should be able to get the certificate and grand temporary/permanent exception for it. In next firefox update the page will change a bit so users don't confuse it with ordinary error page anymore. - Alexander -- 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: firefox and bad ssl certificates
Am Mittwoch, den 07.05.2008, 10:31 +0200 schrieb Peio Ziarsolo: > Hello everybody, > I have found different behaviours between firefox 2 and firefox3 when > they detect a bad ssl certificate. > Firefox 2, when detects the bad certificate warms you about it and give > you the choise to carry on. > Firefox 3, when detects the bad certificates, it show you a error page > and doesn't allow you to look at it. > > I would like to know before report like a bug if this is a new security > feature or if it is just a bug. It's annoniying not be able to look at a > lot of web pages. It *is* different behavior; However, if you read the whole error message, you will find a way to download the "bad" certificate and add it to a whitelist, thus allowing to view the page. It's a bit more difficult to do than earlier, but it protects the user better from bad websites. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- 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
firefox and bad ssl certificates
Hello everybody, I have found different behaviours between firefox 2 and firefox3 when they detect a bad ssl certificate. Firefox 2, when detects the bad certificate warms you about it and give you the choise to carry on. Firefox 3, when detects the bad certificates, it show you a error page and doesn't allow you to look at it. I would like to know before report like a bug if this is a new security feature or if it is just a bug. It's annoniying not be able to look at a lot of web pages. thanks in advance p. -- “Es imposible que una persona aprenda lo que cree que ya sabe.” Epicteto -- 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
True the lack of X would cause a problem, but that is when the "helper" could resort to the SSH option. It is also possible to make this an addition option, maybe: remote-recovery --gui and remote-recovery --cli and remote-recovery --both With the --both being the default? This gives a bit more control, and I am sure even a new user can type the extra option in for the command, and with a GTK frontend this should't be a problem at all. As per your note on ssh, and key based authentication. Even internally, key-authentication is smarter, more secure, and ultimatly easier. It is easier to manage keys and access. It would be a wise, sane default. Passwords are a stupid (authentication) mechanism and are being phased out more-and-more. And if you want to run password authentication internally it is a quick and easy change, in one file. It think it is more wise to go with a secure default, and allow the experience users to deviate from the default, then to ship a less-secure option with the hopes that people will know when to enable it. Thanks, Justin M. Wray Sent via BlackBerry by AT&T -Original Message- From: Milan Bouchet-Valat <[EMAIL PROTECTED]> Date: Wed, 07 May 2008 10:00:31 To:[EMAIL PROTECTED] Cc:Christopher Halse Rogers <[EMAIL PROTECTED]>, Andrew Sayers <[EMAIL PROTECTED]>, ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier Le mercredi 07 mai 2008 à 03:44 +, Justin M. Wray a écrit : > 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. If you limit your goal in this spec to "general help" (as opposed to "recovery from an unusable system"), then you can do it in a nice and easy way with Telepathy. The "newbie" only has to select his technical friend while they chat on Empathy, and say "Give this contact control on my desktop". Then if a console is needed the geek will start it by itself (gnome-terminal). The drawback here is that in case X does not start anymore, this would not work. But for the most common case of a new Linux user asking "how can I do that", this is perfect since you can see what the friend is doing, and possibily learn. And this is nicer because you don't give total control on the computer to a friend who may install what he wants (even if you trust him, this possibility may refrain you from remote help). A word about openssh-server: Please don't disable password connexions by default, it is your script that will have to do so. The defaults now are sane and quick to use. Many people are behind firewalls and can install a SSH server without fear of terrible attacks on their LANs. Only when the user is known to be a newbie not controlling the SSH server we should secure it the most. Very nice idea anyway! -- 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
Le mercredi 07 mai 2008 à 03:44 +, Justin M. Wray a écrit : > 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. If you limit your goal in this spec to "general help" (as opposed to "recovery from an unusable system"), then you can do it in a nice and easy way with Telepathy. The "newbie" only has to select his technical friend while they chat on Empathy, and say "Give this contact control on my desktop". Then if a console is needed the geek will start it by itself (gnome-terminal). The drawback here is that in case X does not start anymore, this would not work. But for the most common case of a new Linux user asking "how can I do that", this is perfect since you can see what the friend is doing, and possibily learn. And this is nicer because you don't give total control on the computer to a friend who may install what he wants (even if you trust him, this possibility may refrain you from remote help). A word about openssh-server: Please don't disable password connexions by default, it is your script that will have to do so. The defaults now are sane and quick to use. Many people are behind firewalls and can install a SSH server without fear of terrible attacks on their LANs. Only when the user is known to be a newbie not controlling the SSH server we should secure it the most. Very nice idea anyway! -- 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
