[omniORB] [help] [beginner] cannot run naming service examples from python chapter 2 "The Basics"

[Alistair Bayley]

> omniNames is configured in a fishy way:
>
> $ catior
> IOR:010000002b00000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e300000010000000000000090000000010102000a0000006c6f63616c686f737400f80a0b0000004e616d6553657276696365000400000000000000080000000100000000545441010000001c00000001000000010001000100000001000105090101000100000009010100030000001a000000010000000f0000003137322e33302e3133352e3135300000f90a00000354544108000000a027434e01003e99
> Type ID: "IDL:omg.org/CosNaming/NamingContextExt:1.0"
> Profiles:
> 1. IIOP 1.2 localhost 2808 "NameService"
>            TAG_ORB_TYPE omniORB
>            TAG_CODE_SETS char native code set: ISO-8859-1
>                          char conversion code set: UTF-8
>                          wchar native code set: UTF-16
>                          wchar conversion code set: UTF-16
>
>            TAG_ALTERNATE_IIOP_ADDRESS 172.30.135.150 2809
>            TAG_OMNIORB_PERSISTENT_ID a027434e01003e99
>
>
> It is publishing endpoints localhost:2808 and 172.30.135.150:2809. We
> can't tell from the IOR exactly how it is listening on those endpoints,
> but my guess is that it is bound specifically to localhost on port 2808
> and 172.30.135.150 on port 2809, meaning that when your client tries to
> connect to localhost:2809, the connection is rejected.
>
> How is omniNames invoked?  if you haven't done anything to it, I suspect
> there's a bug in the Ubuntu package.

I have modified the /etc/omniORB4.cfg, so it's probably my fault. I
won't be able to test this until Thursday, so I'll let you know then.

Thanks,
Alistair