Re: Interix Installation Issue - apparently solved
On Tue, Apr 14, 2009 at 11:40:04AM +0200, Martin Koeppe wrote:
>
> On Mon, 13 Apr 2009, Brian Amundsen wrote:
>
>> Martin,
>>
>> I'm sorry for sending the last request of assistance. I notice
>> that to install anything I must be logged in to windows as the
>> Administrator and then start my ksh. Thought I could do this from a
>> windows user account as long as my ksh is logged in as Administrator?
>
> Ok, I'll change the install doc to reflect this on XP also, not only
> Vista.
While you are at it Mr. Koeppe, you may wish to update the bit about
pinning debian-interix packages for interix versions > 3.5; when I was
experimenting with Vista I thought I should pin "unreleased60" and
"unreleased52" as well as "unreleased35", but this isn't obvious, and
I wasn't sure if I should pin them all at the same priority or give
later version repositories higher pin priorities.
Or maybe I was wrong entirely about the whole pinning thing.
>> I'm guessing this is a su issue that I'm mistaking or an security
>> inheritance issue that is unresolved.
>
> On Interix "Administrator" and "Administrators Group" are different.
> Only "Administrator" has full power.
I wish I understood this better. I've been doing APT upgrades su'd to
root under Interix and haven't had any trouble yet, but I'm beginning
to get the impression that this also will cause problems eventually,
even though `id -u` reports the correct UID for Administrator.
I spent a little bit of time searching the interopsystems forum for
information on these permission issues but didn't turn up anything.
Does anyone have a pointer to some exposition of the permissions
issues?
Is the problem fully understood? I had a problem when installing some
daemon or another because the "staff" group didn't exist, which I
fixed by mapping the staff group to the Adminstrators group using the
Windows GUI for User Name Mapping and passwd and group files from
a Debian-linux install.
All of which is to say: I'm sure I should read up on User Name
Mapping because I don't half understand what I actually did to make
that work, but it would be good to know what's already known about
this sort of thing before I begin. (I'll probably need to consult some
UNIX docs too, come to think of it, but I'm sure I can find those.)
I also get the feeling that these user and group issues are going to
be a problem for the Interix port going forward, particularly for
UIDs < 100. Again, I'm still more-or-less guessing; I haven't done my
homework on this stuff yet, and this sort of thing is to be expected
in a young port.
>> I notice that the windows user (Administrator group) also is skipping
>> the PATH for sbin and usr/sbin.
>
> On a standard SFU installation neither /sbin nor /usr/sbin is in PATH
> for any user. You need therefore to change that.
>
>> Also when I login as Administrator it is stating an error with the
>> profile/lcl. Maybe this is all just a matter of me recalling the
>> security issues behind UNIX. If I read OpenBSD manual will it help, or
>> is Interix or Microsoft TechNet better for these issues?
>
> I think any Unix/Linux doc on bourne shells and /etc/profile will be ok.
>
>> I reran the apt-get update and apt-get upgrade, everything completed
>> correctly and the dpkg -l is clean for all packages. I then setup your
>> suggest PIN preferences file to keep from upgrading to undesirable
>> packages.
While trying to install xterm I found that the "ucf" package has a
dependancy on "coreutils" that isn't satified by the dummy coreutils
"providing" coreutils. As I got into it, I saw that "ucf"
really does depend on GNU "coreutils", at least at install time. So I
concluded that it was probably intentional, and didn't bring it up
here. Now that I'm writing anyway, I thought I should mention it, if
only for the archives.
I ended up installing the "coreutils" package out of debian-interix
experimental to get around that; if something breaks I will no doubt
get to keep both pieces. Maybe if I'd played with "equivs" and only
extracted the offending binary "ucf" wants I could have gotten around
that.
In the same vein, I also had a problem with "x11-common" complaining
about /usr/X11R6/bin not being empty, as it wanted to symlink the
directory to /usr/bin. I got around that by moving /usr/X11R6/bin out
of the way, then copying back only the files that did not exist after
the "x11-common" package had done its thing. This seems to have
worked so far.
Thank you, Martin, for making this port, as thank you also to anyone
else who has contributed; I was very happy to see that work is being
done to build a Debian environment for Interix.
--
Joseph Fannin
jfannin@gmail.com
Reply to: