Re: Interix Installation Issue - apparently solved
On Tue, 14 Apr 2009, Joseph Fannin wrote:
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.
It isn't obvious. But whatever you did is ok, because unreleased52 and
unreleased60 contain 0 packages, and will not receive packages any
time soon. So you don't need unreleased52 and unreleased60 at all, and
the installer could be modified to not create those entries.
I created unreleased{52,60} at a time where I didn't fully understand
the shared library problems which can result from building different
packages on different systems. Simple example: A program which
depends on a libfoo should be linked to the same libc as libfoo has
been linked to, or you end up in having 2 libcs in one process,
probably a bad idea.
Or maybe I was wrong entirely about the whole pinning thing.
I think you aren't wrong. It is problematic to have several concurrent
libc / libncurses / ... or whatever is shipped by MS. The final goal
must be to have an own libc (glibc?) ported to debian-interix which
can be installed on every Interix kernel (3.5/5.2/6.0) version, just
as on Linux libc is the same for kernel 2.2/2.4/2.6.
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.
This shouldn't cause problems, but reportedly it has caused problems,
so I tightened the preconditions. I didn't do any researches on this
topic yet, I only use Administrator. Help on this is welcomed. This is
probably something Rodney could say more about.
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.
Non-existing "staff" is currently a bug in the debian-interix patch. I
have /bin/chown a symlink to /bin/true sometimes to get over those
issues. Or it's some arch:all package which thinks "staff" is
available everywhere. I didn't any research in these users and groups
with id<100. Help is welcomed.
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.)
You really got it working with User Name Mapping? I thought this is
only for NFS servers, not for local Interix processes.
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.
Right, this is a serious problem. but a small one compared to all
problems I have seen so far during the 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.
This is not intentional. It's just a bug in the Interix package which
I overlooked (because of /bin/chown linked to /bin/true). I'll fix
this one. And it's difficult to check the whole archive for broken
dependencies automatically, because there are obviously many of them
because an arch:all package from sid depends on a binary package not
ported to debian-interix.
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.
A good coreutils package is also a TODO item.
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.
IIRC, I did that manually, too, some time ago. A good postinstall
script is defitely missing here.
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.
Thanks for your input.
Martin
Reply to: