Communication OPSI Server -> Managed Client

[Earwain]

Hi all,

We're evaluating OPSI and quite impressed with the scope of the tool!
The main issue I'm still facing is the possibility to "push" actions to the clients, at other events than Startup.

We have clients that hibernate/wake up their portables for months, without ever restarting unless they really have to.

The "Trigger-Push-Event" seems not to work too reliably at the moment however:
Here are some findings:

1) works rather fine with most recent OPSI Client Service, when on the original IP address
2) can't get "Fire Push Event" or Notification Popup working when client X, original IP address "a.b.c.d" has now been assigned "a.b.c.f" because its IP address was scavenged, or because he's connecting through VPN.
yet:
- from the OPSI server, I can ping the client using FQDN succesfully

My question: when the control webservice at the client is approached by the OPSI control server, what IP is used by the server to find the client:
- the one in client.ini (often wrong) or
- the one derived from a FQDN lookup? (DNS/broadcast)

If through lookup, is my test to ping client FQDN sufficient? Where's the log on the server showing me why it can't connect?

Second - but I think this is a "major" request: is there any product roadmap for "queued" events w/o being triggered by startup?
i.e. "push out" an update to all clients, and the client picks up the request when opsiclientd connects next time to the config server, at that moment running the equivalent of a "push triggered event". This would bring OPSI truly on par with Microsoft SMS / System Center Configuration Manager!

Thanks, and keep up the good work!

Krgds,
Koen, Neddine ICT Consultants & Architects, Belgium.

[d.oertel]

Hi,

My question: when the control webservice at the client is approached by the OPSI control server, what IP is used by the server to find the client:
- the one in client.ini (often wrong) or
- the one derived from a FQDN lookup? (DNS/broadcast)

I didn't look at the code - but I think we use the DNS lookup

Where's the log on the server showing me why it can't connect?

Every thing you do at the management interface is translated to one (or more) web service calls to the servers opsiconfd process.
So you will find the logs at /var/log/opsi/opsiconfd/<ip-number-of-box-where-the-management-interface-is-running>.log
Perhaps you need to increase the loglevel in the /etc/opsi/opsiconfd.conf (and reload the opsiconfd)

is there any product roadmap for "queued" events w/o being triggered by startup?
i.e. "push out" an update to all clients, and the client picks up the request when opsiclientd connects next time to the config server, at that moment running the equivalent of a "push triggered event".

I'm not sure what you mean. If you set for a product the action request 'setup' this will be handled by the client, the next time the client agent will be fired by a event. The default event is the system startup (gui_startup). There are some other events in the opsi-client-agent configuration that can be activated. So my question is: what should trigger the start of the installation ?


A additional information: opsi can be completely managed at the command line. So you you may work with scripts and cron jobs.

regards
d.oertel

[wolfbardo]

My question: when the control webservice at the client is approached by the OPSI control server, what IP is used by the server to find the client:
- the one in client.ini (often wrong) or
- the one derived from a FQDN lookup? (DNS/broadcast)

depends on the config of the opsiconfd

Code: Alles auswählen

/etc/opsi/opsiconfd.conf

and the setting of

resolve ip

regards
Bardo Wolf

[Earwain]

Hi Bardo,

Thanks for your answer!
However, the file /etc/opsi/opsiconfd.conf has 2 related settings:
verify IP
update IP

but no
resolve IP

Was that a small typo, or should I add the parameter you mentioned?
I'll test by setting both verify & update to "Yes".

Tnx

Koen.

[wolfbardo]

Hi Koen,

Was that a small typo?

yes!

and I would recommend using "yes" instead of "Yes"

regards,
Bardo Wolf

[d.oertel]

Hi,

i just asked the developer:
The opsiconfd looks in the first step if there is a IP number in the opsi database.
If there is no IP number, the opsiconfd try a DNS lookup.

The opstion 'update IP = yes' means that a client's ip address will be updated in the opsi database, when the client connects to the service and authentication is successful.

('verify ip' has nothing to do with the problem which ip address is used and the default is 'no')

regards

d.oertel

[Earwain]

Hi,

Sorry for the delay, I accidentally unsubscribed following this thread by email.

I understand. So, theoretically:

- a client CLIENT01 installs opsiclientd while it has IP address 192.168.2.100
- the computer is used elsewhere, DHCP times out, and another PC, CLIENT02, gets address 192.168.2.100. This one has no OPSICLIENTD installed yet.
- CLIENT01 gets back to the office and is now given 192.168.2.101 by DHCP
- I trigger an action on CLIENT01 which in OPSI database has still 192.168.2.110
- Now, this IP will not answer since OPSICLIENTD is not installed (and if it were, woudl have another PC Key)
- so I get a timeout.

This is the issue we're facing regularly since our internal employees are IT Consultants, and all computers are laptops used in very different networks all of the time.

Would solving this need the VPN Module functionality (under co-development)?

Thanks,
Krgds
Koen.

[d.oertel]

Hi,

yes, I think you understand.

Some background: There are very different network situations at our customers. Often the clients can't be resolved via DNS (or not correctly). Therefore the opsi-server may use it's own database to resolve the client's IP. I think that it is easy possible to add the the feature that it is possible to switch between 'DNS first' and 'internal database first' by configuration.
If you need this feature we can make a calculation and a offer.

Now some information to the WAN/VPN extension:
The laptops of traveling IT-Consultants normally are not in the companies LAN. So it makes no sense to try to connect the opsi server at boot time. The opsi-client-agent is event driven. This means we can define at which event it becomes active. One possibility is to define to become active if the VPN network interface become active. This feature is implemented right now. The second problem is, that you may install some smaller packages on the fly via WAN. But it is (for example) no good idea to install a Office package via a slow WAN connection. Therefore the client should see that a package is bigger than a configurable threshold and start to download the package in the background. This package caching may go over mor than one session and installation starts if the complete package is stored locally.

At the moment we work at this feature and we hope to finish it at the end of March 2011.

Did this Information help you ?

regards

d.oertel

[Earwain]

Hi,

Very clear indeed - thank you for your time.

Thanks to this thread, I have found the solution to my problem:

- I have removed the IP address from the clients in the OPSI database
- I have changed the "Update IP" setting in opsiclientd.conf to "no"

Now, OPSI uses FQDN lookup (which works very well, we have a well-maintained DNS) and the fire on-demand-event works flawlessly now.

The to-be VPN functionality you describe would make a really nice asset indeed - very similar to Microsoft's BITS protocol usage when SMS/System Center Configuration Manager is used.

A bit higher-up in this thread, I was not too clear about the request to "push to an offline client" but now I can make it more clear.

Scenario:
- a user with portable LAPTOP1.ACME.COM is configued in OPSI database (without IP)
- an OPSI administrator fires the "on-demand" event for all users of ACME.COM

Three options:
A - the user is online: the event is triggered and runs (SUPPORTED - works fine!)
B - the user is online over VPN: with the above solution, when VPN updates LAPTOP1 in DNS, the event will be triggered over WAN. (SUPPORTED, but not recommended for large packages)
C - the user is offline: now, OPSI will issue a "timeout".

And this is what I meant earlier: can we put it on the roadmap that this triggered event is not timed out, but instead "cached" at the server.
Idea: when opsiclientd of LAPTOP1.ACME.COM comes onlines, it would contact the server anyway, find the pending action, and execute.

I realize this is a feature request - but is it anywhere on the roadmap yet?
My problem is that more and more users never reboot their computers, and arrive in the office without booting up - hence missing the action requests "setup" and "uninstall" for weeks.

Thanks,
Koen.

[d.oertel]

Hi,

And this is what I meant earlier: can we put it on the roadmap that this triggered event is not timed out, but instead "cached" at the server.
Idea: when opsiclientd of LAPTOP1.ACME.COM comes onlines, it would contact the server anyway, find the pending action, and execute.

I realize this is a feature request - but is it anywhere on the roadmap yet?
My problem is that more and more users never reboot their computers, and arrive in the office without booting up - hence missing the action requests "setup" and "uninstall" for weeks.

There are two ways to do this:

1. From the Server: Implemeting the possibility to define Jobs at the server which can be executed controled by something like a cron job.

2. From the Client: The actionrequest is set correctly, so it will be executed the next time the agent will be active. The opsi-client-agent is event driven. So you may use one of the existing events (event_user_login, or event_vpn_startup defined by a wql statement). There is also the possibilty to define here a new event type which is time driven.

As far I can see the possibility 2. is easier to implement.
But it is not on the roadmap at the moment. But the roadmap can be changed with money .....

regards

d.oertel