Mail Archives: cygwin/2008/11/20/16:49:33
On 20 Nov 2008 11:37:23 +0100, Corinna Vinschen wrote:
> > Note, I'm not requesting any changes. I'm just trying to understand if we
> > could/should establish guidelines for admin tasks requiring elevation.
>
> All nice points but I don't think that you have to convince anybody that
> better documentation and scripts which work better in any environment
> are preferrable. The point is, http://cygwin.com/acronyms/#SHTDI
> We can discuss stuff like that at great length but it won't help
> anybody if the docs and code doesn't get fixed along these lines.
OTOH, if you can't discuss stuff before patching, you're more likely to
get garbage. Witness the last guy who tried.
> Be a part of the project and suggest documentation patches as you see
> fit, or create code patches for scripts to make them more intelligent.
Um, that's what I was trying to do. It just that I'm not a big fan of the
"patch first, discuss later" philosophy, especially when I'm in unfamiliar
territory. I usually try to get agreement on a gameplan first, then
execute.
Lucky for me too, since what I saw fit was already wrong twice on this
elevation issue...
> That would help other users and us maintainers a lot. None of us has
> access to all possible environments/systems and can care for all border
> cases. Or take the next step and be a maintainer yourself. In most
> cases it's not as much work in the long run as you think it is in the
> beginning (when creating your package(s) the first time).
I'm probably not maintainer material. I don't care to discuss it on this
list, but it has nothing to do with the mechanics of maintaining a
package. If you'd like to discuss it or convince me otherwise, you may
contact me personally.
> Talking about Vista migration. From Cygwin's point of view Vista
> is just another OS. The user is just another user. Either the user
> has certain privileges or not. A function works or returns EACCES.
> That's all. Elevation is not an issue for Cygwin, for pretty dumb
> technical reasons.
Though it is an issue from the cygwin user's point of view.
But I do understand where you are coming from. Microsoft also took the
same approach (nothing was done to ease the pain of using Windows command
line tools requiring elevation). Not that that necessarily makes it
http://acronyms.thefreedictionary.com/TRTTD ...
> The only concession *I* would be willing to make
> (but that's just me) is to add some text to admin scripts along these
> lines:
>
> *** Alarm! I couldn't create file foo.
> *** You're missing privileges. If you're admin user and running
> *** on Vista, did you think to run the script in an elevated shell?
That's actually decently close to what I was asking about. Though the
error statement could be qualified with (onVista && !elevated), and some
scripts which don't make sense without elevation (e.g. ssh-host-config)
could just test for that right from the get-go. Plus there's no reason
that compiled commands couldn't do something similar (e.g. "regtool add").
Any code requiring elevation is obviously already cygwin specific.
But, it sounds to me like that is not worth doing and/or not desirable.
That's a perfectly good answer. And I'm fine with that, believe me. An
answer is all I was looking for.
So, to summarize this thread and move on:
1) vista specific documentation is welcome
2) patches to csih/ssh-host-config for 1.7+vista+domain users are welcome
3) patches for elevation issues are not
I'm willing to take a whack at 1), so if anyone has any specific topics
that should be covered or any hints on where this documentation belongs,
please let me know. Else, I'll just do as I see fit.
I sould also like to address 2), but I am now in the boat of not having
access to the required environments/systems. So I can't commit to that
one.
Herb.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -