Big news! The community will be moving to a new platform April 21. Read more.
Big news! The community will be moving to a new platform April 21. Read more.
Absent Member.
Absent Member.
2792 views

Manage Connections is missing in NoRM

On one of my OES2 servers, the Manage Connections link is missing from NoRM (Remote Manager). The Manage NCP Services section is there, but there are only two items under that heading: View Inventory Reports and View Trustee Reports. I am missing several options, including Manage Connections.

Any suggestions on how to fix this?

(While I can use the command line to get at what I need, this particular task is way faster via NoRM, and not everyone in our department is comfortable using the command line.)

Rick P.
Labels (2)
0 Likes
15 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Out of curiosity, are you logged in as "root"?

I've had sometimes where another admin user (in the LUM-enabled admingrp) doesn't show up right.

If you are logged in as root, I've also had memory issues crop up and a reboot of the server has magically fixed NRM.
0 Likes
Absent Member.
Absent Member.

No, I am not logged in as root; I am using our eDirectory admin user. I just tried root, but it acts the same. This problem has been plaguing us since the server was installed, so it has gone through multiple reboots and software patches. Nothing "obvious" seems to help.

Rick
0 Likes
Absent Member.
Absent Member.

I do not have any NCP volumes installed on this server, so I wonder if that is the problem? Perhaps someone at Novell decided that if there are no NCP volumes on the server that you should not need to manage NCP connections? However, user connections are established with this server all the time, automatically, so I need a way to manage those connections quickly and easily. This server contains a RW replica of all our eDirectory partitions, which is probably why user connections happen, although it is somewhat of a mystery to me why this happens.

Rick
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

any change in behaviour if you use a somewhat "direct" link such as

https://xxx.xxx.xxx.xxx:8009/ncpdcons
If you like it: like it.
0 Likes
Absent Member.
Absent Member.

Nope, just a perfectly blank page, no headers, columns or anything.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

with the given info i'd really try to share a little directory in the ext3 system via ncp, restart the httpstk daemon (or the entire box, if time permits) and recheck. most people keep the sys share lurking around, this might explain why we haven't seen this behaviour yet.
If you like it: like it.
0 Likes
Absent Member.
Absent Member.

On Tue, 26 Feb 2013 17:06:01 +0000, RPummel wrote:

> I do not have any NCP volumes installed on this server, so I wonder if
> that is the problem?


Possibly. It seems reasonable. You could test it by creating a volume, to
see if that changes what NoRM displays.


> connections? However, user connections are established with this server
> all the time, automatically, so I need a way to manage those connections
> quickly and easily. This server contains a RW replica of all our
> eDirectory partitions, which is probably why user connections happen,
> although it is somewhat of a mystery to me why this happens.


Short answer: Because this server has eDirectory on it.

Longer answer: When the client needs something from eDirectory, it makes
a series of requests to find a server that can satisfy its needs. The
client has several heuristics, some of which are tunable, that it uses to
decide which servers to make attachments to. It usually tries to use
existing connections when possible, rather than creating new ones. It
tries to use the "closest" available server (ping times), rather than
finding and using ones that are further away or slower to respond. But,
in the end, if a server can satisfy a request from a client, then you
will see clients attached to it.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

RPummel;2249000 wrote:
I do not have any NCP volumes installed on this server, so I wonder if that is the problem? Perhaps someone at Novell decided that if there are no NCP volumes on the server that you should not need to manage NCP connections? However, user connections are established with this server all the time, automatically, so I need a way to manage those connections quickly and easily. This server contains a RW replica of all our eDirectory partitions, which is probably why user connections happen, although it is somewhat of a mystery to me why this happens.

Rick


Odd, because I thought if you installed OES and selected eDirectory/NCP patterns, it would create a "SYS" volume NCP share that's really binding NCP to the:
/usr/novell/sys

directory

In fact, I Just double-checked on my "IDM" only OES2 SP3 server. I ONLY have the "default" SYS NCP share and I can manage connections.
0 Likes
Absent Member.
Absent Member.

kjhurni;2249040 wrote:
Odd, because I thought if you installed OES and selected eDirectory/NCP patterns, it would create a "SYS" volume NCP share that's really binding NCP to the: /usr/novell/sys directory
In fact, I Just double-checked on my "IDM" only OES2 SP3 server. I ONLY have the "default" SYS NCP share and I can manage connections.


Well, to correct myself, the folder /usr/novell/sys is indeed being shared as an NCP volume. I am not sure how I missed that before. However, when I look in NoRM under the View File System section and click on NCP Volume Inventory, the column headings show up, but there is nothing beneath them where the list of NCP volumes (sys in this case) should be. That, combined with the fact that most of the links under the Manage NCP Services heading are missing makes me wonder what is going on.

Rick
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

RPummel;2249086 wrote:
Well, to correct myself, the folder /usr/novell/sys is indeed being shared as an NCP volume. I am not sure how I missed that before. However, when I look in NoRM under the View File System section and click on NCP Volume Inventory, the column headings show up, but there is nothing beneath them where the list of NCP volumes (sys in this case) should be. That, combined with the fact that most of the links under the Manage NCP Services heading are missing makes me wonder what is going on.

Rick


any useful info in the log? afaik, norm logs to /var/log/messages, so just grep for httpstk there.
If you like it: like it.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

RPummel;2249086 wrote:
Well, to correct myself, the folder /usr/novell/sys is indeed being shared as an NCP volume. I am not sure how I missed that before. However, when I look in NoRM under the View File System section and click on NCP Volume Inventory, the column headings show up, but there is nothing beneath them where the list of NCP volumes (sys in this case) should be. That, combined with the fact that most of the links under the Manage NCP Services heading are missing makes me wonder what is going on.

Rick


I've only had this happen to me once, where the default "share" didn't show up in NRM

I simply added it manually.

Maybe try that and see what happens?

Although when it happened to me, I don't remember if I could actually map an NCP drive from my pc to the share or not (meaning BEFORE I manually added it again)
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.