SSHD install failing (Full Version)

All Forums >> [SFU / Interix / SUA Technology] >> Interix Advanced Forum



Message


higgs_bo -> SSHD install failing (Aug. 29, '06, 4:23:39 PM)

SSHD eval copy install failing with what appears to be pkg_add errors:




































































































































































































































































We will now do configuration of the installation.

Check that the most current Interix installer is installed.

Starting checks for updates
Done.
The most current Interix installer is installed.
Checking for shared library support
Adding needed shared library support
usage: tar -{txru}[cevfbmopwBHLPX014578] [tapefile] [blocksize] file1 file2...
pkg_add(sharedgcc-5.2.0-bin): tar extract of /dev/fs/C/Program Files (x86)/Inter
opSecureShell/5.2-authenticamd/sharedgcc-5.2.0-bin.tgz failed!
pkg_add(sharedgcc-5.2.0-bin): unable to extract table of contents from `/dev/fs/
C/Program Files (x86)/InteropSecureShell/5.2-authenticamd/sharedgcc-5.2.0-bin.tg
z'
Is this a Package, or a simple .tgz archive ? See tar(1).
usage: tar -{txru}[cevfbmopwBHLPX014578] [tapefile] [blocksize] file1 file2...
pkg_add(sharedlibs-5.2.0-bin): tar extract of /dev/fs/C/Program Files (x86)/Inte
ropSecureShell/5.2-authenticamd/sharedlibs-5.2.0-bin.tgz failed!
pkg_add(sharedlibs-5.2.0-bin): unable to extract table of contents from `/dev/fs
/C/Program Files (x86)/InteropSecureShell/5.2-authenticamd/sharedlibs-5.2.0-bin.
tgz'
Is this a Package, or a simple .tgz archive ? See tar(1).
Shared library support added
Configuring InteropSecureShell packages/components.
Resolve any conflicts first.
Resolve all packages now.

Starting checks for updates
Trying to add/update package issh
usage: tar -{txru}[cevfbmopwBHLPX014578] [tapefile] [blocksize] file1 file2...
pkg_add(issh-4.2.0.2-bin): tar extract of /dev/fs/C/Program Files (x86)/InteropS
ecureShell/3.5-x86/issh-4.2.0.2-bin.tgz failed!
pkg_add(issh-4.2.0.2-bin): unable to extract table of contents from `/dev/fs/C/P
rogram Files (x86)/InteropSecureShell/3.5-x86/issh-4.2.0.2-bin.tgz'
Is this a Package, or a simple .tgz archive ? See tar(1).
pkg_update: Problem updating package. Continuing. : Undefined error: 0
Done.
All packages/components are now installed and configured.

Press the Enter key to continue


Anybody else experiencing the same problem?

This works on several other machines. The servers are identical in OS, os version, cpus, Service packs, SUA version.




gwojan -> RE: SSHD install failing (Aug. 29, '06, 4:44:06 PM)

Make sure you're logged on as the user you originally installed the SFU/Interop tools with. I just ran into the same thing with the non-eval version. I forgot to log on as the local administrator and screwed things up royally. I know you should be able to do this as a member of the local administrators group but it doesn't work for me. If I originally installed SFU/tools as a member of the local administrators group which is my normal domain account everything works fine. It just doesn't work the other way around. <sigh>

I ended up uninstalling and then cleaning up the stuff left behind in /var/db/pkg -- the stuff that pkg_add failed on, and then reinstalling. Now I'm fat'n happy.[:)]

--Greg




higgs_bo -> RE: SSHD install failing (Aug. 29, '06, 6:23:38 PM)

Greg,
Thanks for the info. It's funny here because we are DBAs members of the administrators group and can install SSHD fine on other identical hosts.
The difference on this install was the addition of the SDK. Apparently the SA that installed the SDK had trouble re-installing SUA and the SDK.

It appears the un-install is the process that does not work correctly. FIle timestamps exist from the original SUA install.

I'm having an SA completely remove the files/dirs and edit the registry.

We'll see if the re - install works.

Thanks again,
-Tracy




gwojan -> RE: SSHD install failing (Aug. 30, '06, 11:09:02 AM)

There's nothing in the registry that I can tell that would really affect the install. All the problems I've had result from the default Windows permissions applied to the SUA/SFU install directory. I'm not sure who actually sets/resets Windows permissions -- the SFU/SUA or the tools install.

If I look at the perms on the SFU/SUA on a machine in which I installed the tools as the local Administrator -- the local Administrator account is the only one that has write privilges into the /var/db/pkg directory. The Administrators GROUP only has read/execute privs.

--Greg




Rodney -> RE: SSHD install failing (Aug. 30, '06, 12:38:36 PM)

If you do a "chmod g+w /var/db /var/db/pkg" that should clear it up.

I spent last night looking into this more. I've made changes to the pkg
tools to check and correct this on a go-forward basis for the default location
and any location named by the environment variables. There are some other updates
and extensions too. I hope to release this later today. I have to roll through
and update the CD's after that (which will take longer).




gwojan -> RE: SSHD install failing (Aug. 30, '06, 3:47:35 PM)

AWESOME! [:D]

I've been trying to keep track of the various conditions where this problem occurs but have never had the time to write it up to send to you. <sigh> Maybe now I won't have to... Anyway, I'll do my best/worst to try and break things for you.[:-]

Along the same line, is there any reference material that discusses the issues of Windows NTFS permissions vs. Interix shell permissions? Am I trying to make things harder than they really are?

In the past it has been mentioned that you shouldn't change perms on the SFU/SUA folders with Explorer. However, I would like to understand some of the reasons for this. I also have an issue with Diskeeper which can't defrag or move certain files around because it doesn't have the necessary rights.

Please try and set my clueless soul straight.[;)]

As usual, thanks for all your help.

--Greg




Rodney -> RE: SSHD install failing (Aug. 30, '06, 6:03:59 PM)

> Anyway, I'll do my best/worst to try and break things for you. [:-]

thanks, I think [8D]
It's something that showed up elusively. Your posting helped clarify it. thanks.

> Along the same line, is there any reference material that discusses the issues of Windows NTFS permissions vs. Interix shell permissions? Am I trying to make things harder than they really are?

The Interix/Unix permissions that you see are interpretations of the underlying filesystems permissions.
Whatever the fileystem the permissions are still kept on that filesystem as "native" (for lack of a better term).

References, mmm, I remember Mark wrote something up about 10 years ago. But I don't know where that is now.
I might see Mark or John (the guy who was the Tech Writer at Softway) in a couple hours. I'll ask them.

For NTFS it can be as simple as 3 ACE's in the ACL. But it's usually more to ensure proper behavior.
So often there is a deny ACE or two added in. A twisted example is when a file denies the user/owner read
permission while group and other can read the file.

> In the past it has been mentioned that you shouldn't change perms on the SFU/SUA folders with Explorer. However, I would like to understand some of the reasons for this.

The simple reason is File Explorer (FE) is an idiot about ACL's.
The order of ACE's in an ACL matter. FE will rearrange the order of the ACE's.
The change of order changes the meaning -- particularly when deny ACE's are involved.
Additionally FE groups or masks settings from the ACE's. What you see is not what
is actually there -- FE is showing its interpretation. So it can result in settings/actions
that you don't want. The "fine control" gets lost. Doing a comparison of the API's to the
behavior of "cacls" and FE can tease this out too -- it's a lot of API reading though.

> Please try and set my clueless soul straight.

I've made the assumption you know about ACL's and ACE's.
But finding a useful web page is hard. I've read some good overviews in books.
Most books just rehash what a Win32 user sees (not useful).
This MS web page is a basic overview of ACL's and ACE's:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/how_dacls_control_access_to_an_object.asp
It's not a lot to read but it gives the clear rules about when access is given or denied.
From this you can see why ACE order matters.




markfunk -> RE: SSHD install failing (Aug. 30, '06, 11:13:58 PM)

here's a link to the white paper I wrote:

http://www.microsoft.com/technet/interopmigration/unix/sfu/sfu3perm.mspx




gwojan -> RE: SSHD install failing (Aug. 31, '06, 9:29:59 AM)

Mark and Rodney,

Thanks for the links. That should get me started and more.[:)]

Mark, I don't know how I missed your whitepaper but I did. <sigh>

Regarding the "evil" behavior of Windows Explorer, I've noticed the same things. Up to this point all of our file services have been on Netware servers and we're now attempting to move away from Netware. Because of this migration I've been working with/writing scripts to do the migration and maintain some semblance of the Netware permissions. I've always wondered why the perms set by cacls/xcacls/etc never seem to be what are displayed in Explorer properties. Your explanation now brings things into focus -- it was the nudge I needed. It's just one more reason for me to hate the Explorer shell...

--Greg




gwojan -> RE: SSHD install failing (Aug. 31, '06, 4:41:15 PM)

Okay, I just updated pkg to 2.7.0 and tried to update 'zip' and this is what I get:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
bash-3.00$ pkg_update -L zip
Your HOME environment variable has a path with spaces in it.
This can cause problems for some applications. Please set a home directory for
this user in the user database without spaces. This really will make things
work better in the long term.

Starting checks for updates
Percent complete/package:
100% |**************************************************| zipMemory fault (core dumped)
pkg_update: Problem updating package. Continuing. : No such file or directory

Done.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Now with verbose logging:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
bash-3.00$ pkg_update -Lv zip
Your HOME environment variable has a path with spaces in it.
This can cause problems for some applications. Please set a home directory for
this user in the user database without spaces. This really will make things
work better in the long term.

adding file list file "/tmp/tmp_AAAAAAAOV"
Starting checks for updates

opening file list file "/tmp/tmp_AAAAAAAOV"
read line: "zip"
basename: "zip"
Going to check for available update to "zip".
getting package by ftp
get ftp info: ftp://ftp.interopsystems.com pkgs/3.5-x86 zip
Update available for "zip". Installing it.
Trying to add/update package zip
pkg_update: Problem updating package. Continuing. : No such file or directory
closing file list file
Done.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Actually the first time I tried to update anything I tried 'pkg_update -Ln' all resulting in core dumps. Now the pkg database thinks all my packages are up to date but the latest versions weren't installed.

The funny thing is I'm using the machine where I've never had any problems installing anything. I'm currently logged on with my domain account which is a member of the local Administrators group.

I even tried su and that fails.

Any ideas?

--Greg

(see I warned you I'd break something...) [:(]




Rodney -> RE: SSHD install failing (Sep. 1, '06, 6:35:43 AM)

But I'm not getting the SEGV you see. It's pkg_add SEGV'ing not pkg_update
by the way the messages appears, which makes it kinda worse for you. It's kinda late
right now -- let me think on it a bit more.




Rodney -> RE: SSHD install failing (Sep. 3, '06, 2:08:27 AM)

I've placed a script at ftp://ftp.interopsystems.com/pub/patchbin for you.
Download the script to, say, "/tmp". Then run it ("sh patchbin") as the
local administrator or member of the administrators group.
Then give it try and do your "pkg_update -a" again.

Let's do any followups on the thread http://www.interopsystems.com/tools/tm.aspx?m=9939
to keep it all in one posting (this thread isn't really the right one now). Thanks.




Page: [1]



Forum Software © ASPPlayground.NET Advanced Edition 2.5 ANSI

0.109