"working DNS"

[inszekt_]

Hi OPSI Staff

We have one central opsi management server and some remote depot server at SMB"s. There are local dhcp servers at every SMB. Our question is: what does it mean `working DNS` related to the OPSI system? " is it needed to resolv the same client to the same name always, independently from the actual, dhcp assigned IP -- for example: one day boss.company.hu is 192.168.2.14 other day boss.company.hu is 192.168.2.45. If we sholud resolv the same client to the same name because it is required by opsi, than we should have a working dynamic dns. OR is it enough to resolv an client ip to an auxilliary hostname, for instance boss.company.hu resolvs to desktop14.company.hu if 192.168.2.14 , desktop45.company.hu if 192.168.2.45 assigned etc?

regards, np

[j.schneider]

You do not need a DNS at all to use opsi.
But it is very important that all the opsi servers do know their own fqdn and the fqdn of the other servers and can resolve the fqdns to ip addresses.
It is sufficient to put the names into the /etc/hosts of every server.

[inszekt_]

we created a depotserver from an opsi server. then we installed a windows xp client, from the depotserver. the automatically installed preloginloader cannot connecting to the depot server and the software installing doesn't work.

this is the logfile of the test client on the depot server (the name of the file is tesztkliens.ringcsoport.hu.log, which is a link which redirect to the 192.168.2.75.log file - which is the IP-address of the windows client computer):

[4] [Jan 17 20:26:51] Authorization request from tesztkliens.ringcsoport.hu@192.168.2.75 (opsiconfd|354)
[3] [Jan 17 20:26:51] Failed to resolve hostname 'tesztkliens.ringcsoport.hu': (-5, 'No address associated with hostname') (opsiconfd|371)
[4] [Jan 17 20:26:51] Host login attempt with username 'tesztkliens.ringcsoport.hu' from ip '192.168.2.75', but name resolves to '[]', ip verification is disabled (access granted) (opsiconfd|384)
[4] [Jan 17 20:26:53] BackendManager created. (opsiconfd|391)
[4] [Jan 17 20:26:58] Client '192.168.2.75' did not send cookie (opsiconfd|261)
[4] [Jan 17 20:26:58] New session created (opsiconfd|950)
[4] [Jan 17 20:26:58] Authorization request from tesztkliens.ringcsoport.hu@192.168.2.75 (opsiconfd|354)
[3] [Jan 17 20:26:58] Failed to resolve hostname 'tesztkliens.ringcsoport.hu': (-5, 'No address associated with hostname') (opsiconfd|371)
[4] [Jan 17 20:26:58] Host login attempt with username 'tesztkliens.ringcsoport.hu' from ip '192.168.2.75', but name resolves to '[]', ip verification is disabled (access granted) (opsiconfd|384)
[4] [Jan 17 20:26:58] BackendManager created. (opsiconfd|391)

and this is the logfile of the client on the central opsi server (the name of the file is tesztkliens.ringcsoport.hu.log, which is a link which redirect to the 192.168.2.3.log file - this is the IP-address of the depot server):

[4] [Jan 17 20:28:41] Authorization request from tesztkliens.ringcsoport.hu@192.168.2.3 (opsiconfd|354)
[3] [Jan 17 20:28:41] Failed to resolve hostname 'tesztkliens.ringcsoport.hu': (-2, 'Name or service not known') (opsiconfd|371)
[4] [Jan 17 20:28:41] Host login attempt with username 'tesztkliens.ringcsoport.hu' from ip '192.168.2.3', but name resolves to '[]', ip verification is disabled (access granted) (opsiconfd|384)
[4] [Jan 17 20:28:41] BackendManager created. (opsiconfd|391)
[4] [Jan 17 20:28:42] Session 'VviWk2kDBReZ4iTGe45Qbwl4ATPVGseQ' deleted (opsiconfd|984)
[4] [Jan 19 13:27:26] Client '192.168.2.3' did not send cookie (opsiconfd|261)
[4] [Jan 19 13:27:26] New session created (opsiconfd|950)
[4] [Jan 19 13:27:26] Authorization request from opsidepot.ringcsoport.hu@192.168.2.3 (opsiconfd|354)
[4] [Jan 19 13:27:26] BackendManager created. (opsiconfd|391)
[4] [Jan 19 13:28:05] Client '192.168.2.3' did not send cookie (opsiconfd|261)
[4] [Jan 19 13:28:05] New session created (opsiconfd|950)
[4] [Jan 19 13:28:05] Authorization request from opsidepot.ringcsoport.hu@192.168.2.3 (opsiconfd|354)
[4] [Jan 19 13:28:05] BackendManager created. (opsiconfd|391)

on the client there is the preloginloader logfile, which is contains the following lines:

[4] [Jan 19 15:01:10] Client '192.168.2.75' did not send cookie (opsiconfd|261)
[4] [Jan 19 15:01:10] New session created (opsiconfd|950)
[4] [Jan 19 15:01:10] Authorization request from @192.168.2.75 (opsiconfd|354)
[2] [Jan 19 15:01:10] Forbidden: Cannot authenticate, no username given (opsiconfd|417)
[1] [Jan 19 15:01:10] Traceback (most recent call last):
File "/usr/sbin/opsiconfd", line 118, in http_GET
return worker.process()
File "/usr/sbin/opsiconfd", line 200, in process
self.deferred.callback(None)
File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line 243, in callback
self._startRunCallbacks(result)
File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line 312, in _startRunCallbacks
self._runCallbacks()
--- <exception caught here> ---
File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line 328, in _runCallbacks
self.result = callback(self.result, *args, **kw)
File "/usr/sbin/opsiconfd", line 356, in _authenticate
raise Exception("Cannot authenticate, no username given")
exceptions.Exception: Cannot authenticate, no username given
(opsiconfd|619)

is it enough that the opsi servers knows each others IP and DNS name (for example by the /etc/hosts file), or a working name resolution between the central opsi server and the depot clients is a must?

regards, np

[d.oertel]

Hi,

is it enough that the opsi servers knows each others IP and DNS name (for example by the /etc/hosts file), or a working name resolution between the central opsi server and the depot clients is a must?

a) the opsi server must be able to resolve its own name in both directions (this can be done by /etc/hosts)

b) a DNS with all clients is not a must. In this cases the netbios name resolution must work in order to mount the shares.
It is usefull in this cases to enable the name resolution over wins on the opsi server by installing the samba winbind package and add 'wins'
to the /etc/nsswitch.conf name resolution line.

regards

d.oertel

[inszekt_]

this is the message of the preloginloader - before this we have a ServiceHost couldn't found (or something similar), but allowing ICMP echo it appears:

[d.oertel]

Hi,
please post the
c:\tmp\logonlog.txt

regards

d.oertel

[inszekt_]

here is the logfile from the client. this is an another client, which has the name alma, but the error is the same.

[d.oertel]

Hi,

Code: Alles auswählen

2010.01.23. 23:24:07     error on trying to connect to opsi service https://172.18.1.2:4447, username "alma.arwin.hu" , message " error: HTTP/1.1 401 Unauthorized"

The client connects as:
alma.arwin.hu
using its pckey (c:\program files\opsi.org\preloginloader\cfg\locked.cfg) as password.
Is there a entry for alma.arwin.hu at the serev in /etc/opsi/pckeys ?
Is there a difference between the keys at the server and at the client ?

regards

d.oertel

[inszekt_]

there is the same pckey for the client alma.arwin.hu but not on the depotserver. i found the key on the central server. how is this possible? I thought the depotserver controls the clients, not the central OPSI server. is OPSI capable for managing multi domain infrastructure?

[d.oertel]

Hi,

ok - you are working on a multi depot environment.
Just give the manual (Chapter 10. opsi-server with multiple depots)
a second look.
The Client have to connect the master (config-server).
A connection to the depot server may fail.
The config server tells the client which depot should be used
for mounting the shares (and so on).....

does this help ?

regards

d.oertel