We just updated to the latest UMS and are seeing problems trying to push updates through the “Universal Update”. The error er are seeing is “could not resolve host name” update.igel.de/pub/lxos.ver, etc.
Was that an in-place upgrade or did you migrate servers? That error typically indicates there is no update package assigned to the thin client or it doesn’t like the one it has currently, so it falls back to an old configuration
I ask about the migration because if you had existing firmware update packages downloaded previously, those are not included in the migration and would need to be re-downloaded or manually moved. You can disregard that part if it was just an in-place upgrade 🙂
If I have something like this a reboot and a push of settings from UMS to device should fix it.
We had the same problem. It appears that the default hostname update.igel.de update.igel.de is referring to an outdated host. We fixed this in two ways:
For intranet hosts
1. We redefined a hostname record across our WAN DNS that overrides the entry for any new unprofiled hosts. This squelches the error on any new thin clients and forces them to pickup updates from our server.
2. We edited the lxos.ver file to a non older non existent version (11.00.01) in our case, to prevent the updates from happening without our knoweldge.
Extranet / Mobile clients
For external mobile workers, we changed the update address as a host file entry in the actual /etc/hosts on the thin client to point to our firmware update point. We mapped the lxos.ver to be processed by our web server as a script file so we know what value to return
hope this helps
I wouldn’t attempt to work around that with a host entry – it’s a symptom, not the root problem 🙂 best practice would be to ensure thin clients always have a valid update package applied to them
Understand your point, since Igel is shipping an OS with an invalid hostname — this was our solution to prevent helpdesk tickets and it works. Perhaps IGEL could fix the invalid hostname in the OS default build?
nslookup google.com google.com 9.9.9.9
Server: 9.9.9.9
Address: 9.9.9.9#53
Non-authoritative answer:
Name: google.com google.com
Address: 172.217.13.78
Name: google.com google.com
Address: 2607:f8b0:4004:80a::200e
$ nslookup update.igel.de update.igel.de 9.9.9.9
Server: 9.9.9.9
Address: 9.9.9.9#53
server can’t find update.igel.de update.igel.de: NXDOMAIN
IMHO raises some testing quality issues when Igel is shipping OS with invalid hostnames
well, there’s not really a valid hostname to set it to – if there isn’t an update profile with valid settings applied to the thin client when an update kicks off, it will revert to legacy settings as a last resort. I do agree that the thin client should just throw an ‘update settings not found’ message or something of the sort, but I couldn’t comment on how simple of a fix that would be
Continue reading and comment on the thread ‘IGEL UMS Universal Update Error: “could not resolve host name”‘. Not a member? Join Here!
Learn more, search the IGEL Knowledge Base
Ask a question or comment on the above message thread?
Join or log in to the IGEL Community to ask us anything and meet other IGEL customers, partners, and EUC enthusiasts.Submit a question, or Join Today!