OK, one thing to note that setting a server port does not override the use
of a portmapper. If you want the server only to run on a port you should
turn of the "Register-With-Portmapper option.
Now, since the reporting problem appears to be a known bug, I understand why
BMC adviced you to use the ARTCPPORT environment variable as that would
override any settings done in the API. And I guess that should have worked,
but it might be that the ARTCPPORT must be set in a specific environment
(depending on your platform). The only problem with the setting would be
that it would override settings for all servers that the Mid-Tier connects
to, but if you only have one server this shouldn't be a problem.
Hugo
On 5/24/07, Enrique Palazuelos <[EMAIL PROTECTED]> wrote:
Hi Hugo and thanks a lot,
Our ARS server is configured to use a tcp port ("TCD-Specific-Port=1234")
which, we think, should override Register-With-Portmapper:T (in fact, AR
System User works correctly asking 1234 TCP Port) Midtier is also
configured
to ask ars server "arsystem.arservers.myhost.mydomain.port=1234".
Midtier ask ars server to 1234 port, but when users try to edit reports
through Midtier, we get a RPC timeout. In this case, Midtier tries to open
an udp port and we can´t explain why. BMC has replied the opened ticket
recommending to upgrade ARS Server (we have 5.01.02 version) and Midtier
(we
have 6.03 patch 12). We can´t upgrade ARS Server because we have a lot of
sources developed for, but we could upgrade Midtier. BMC told us that this
is a known bug, but we have read release notes and there is not reference
to
that bug.
I have a meeting tomorrow and I need to explain the problem and solution,
and I´m not sure about BMC reply.
Regards,
Enrique.
Hugo Visser-3 wrote:
>
> Hi Enrique,
>
> The Register-With-Portmapper setting is only to tell the _server_ that
it
> should use the port mapper. You can have a server run on a specific port
> and
> use the port mapper or only connect on the specified port.
>
> The Mid-Tier is a client to your server, just like the user tool. When
> configure the Mid-Tier to connect on a specific port, it should not use
> the
> port mapper anymore for the specified server.
>
> Setting the ARTCPPORT overrides any settings to the tcp port setting
that
> you can set in either the user tool or Mid-Tier, so you should use that
> only
> for API programs that do not allow you to set the port. You should not
use
> it for the user tool or for the Mid-Tier as it can be very confusing.
> Besides the setting is for all servers, while through the Mid-Tier
> configuration you can set the port per server. Setting it globally on an
> environment sounds like a bad idea to me.
>
> You should confirm that the user tool can connect to the server if it's
> behind the same firewall (or just stop the port mapper if you can). If
it
> can, then your server is configured OK and you should leave the server
> alone
> :) Then you configure the Mid-Tier and test that. Remember that the
> Mid-Tier
> is a client to the AR server.
>
> Hugo
>
> On 5/21/07, Enrique Palazuelos <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> I have checked Mid-Tier configuration through web administrator page
and
>> it
>> appears to be correctly configured.
>>
>> We are doing some tests on preproduction environment. I have change
>> "Register-With-Portmapper" from True to False, and configured
>> Plugin-Port=1233. Clients and Mid-tier have to specify ARTCPPORT
variable
>> and everything appears to work correctly, but now we don´t receive ARS
>> administration messages. We will mantain these configuration during a
>> month,
>> if it works correctly we will apply it on production environment. We
have
>> above 500 users, so we think a lot of time about any change we could
do.
>> Casualty?
>>
>> Regards,
>> Quique.
>>
>>
>> Hugo Visser-3 wrote:
>> >
>> > Hi Enrique,
>> >
>> > Have you checked that the port is specified on the Mid-Tier
>> configuration
>> > page? The Mid-Tier will not use the settings from the ar.conf, but
has
>> > it's
>> > own connection settings page.
>> >
>> > Hugo
>> >
>> > On 5/18/07, Enrique Palazuelos <[EMAIL PROTECTED]> wrote:
>> >>
>> >> I was not suscribed to arslist, I´ve been registered and I hope
anyone
>> >> can
>> >> see my post now.
>> >>
>> >> Thanks a lot.
>> >>
>> >>
>> >>
>> >> Enrique Palazuelos wrote:
>> >> >
>> >> > Hello,
>> >> >
>> >> > This is my first post, please excuse my terrible english.
>> >> >
>> >> > We have an ars server and a midtier server connected to. The ars
>> server
>> >> is
>> >> > configured to use only the artcpport 1234 (for example). In
>> >> preproduction
>> >> > environment Midtier works ok when editing reports. It only open
>> >> > connections on 1234 TCP Port, but in production environment
Midtier
>> >> tries
>> >> > to open an udp port via Sun RPC and gets an RPC timeout, which is
>> >> normal
>> >> > because these ports are closed. The ar.conf files are similar.
>> >> > TCD-Specific-Port is configured to 1234 and works ok, but the
>> Midtier
>> >> > production Server tries to open a different port only when we try
to
>> >> edit
>> >> > a report. We have set the parameter "Register-With-Portmapper: T"
in
>> >> both
>> >> > files, but in preproduction server, these parameter is under the
>> >> > TCD-Specific-Port. In the ars production server TCD-Specific-Port
>> >> > parameter is under "Register-With-Portmapper: T".
>> >> >
>> >> > The order of parameters in the ar.conf is important? Which are the
>> >> > necessary parameters to use only tcp ports? We have a 6.3 Midtier
>> >> Server
>> >> > patch 14 and a 5.1.2 Ars Server.
>> >> >
>> >> > We have open a ticket to BMC. They have purposed to a open a
>> >> pluginreport
>> >> > port, but we can´t open ports without explaining why, and these
port
>> is
>> >> > not configured on preproduction environment and it works ok. We
>> can´t
>> >> > upgrade because development requirements,
>> >> >
>> >> > Any suggestion?
>> >> >
>> >> > Thanks a lot.
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>>
http://www.nabble.com/Midtier-using-RPC-but-ars-is-not-configured-to-tf3757780.html#a10676829
>> >> Sent from the ARS (Action Request System) mailing list archive at
>> >> Nabble.com.
>> >>
>> >>
>> >>
>>
_______________________________________________________________________________
>> >> UNSUBSCRIBE or access ARSlist Archives at
>> www.arslist.orgARSlist:"Where
>> >> the Answers Are"
>> >>
>> >
>> >
>>
_______________________________________________________________________________
>> > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> ARSlist:"Where
>> > the Answers Are"
>> >
>> >
>>
>> --
>> View this message in context:
>>
http://www.nabble.com/Midtier-using-RPC-but-ars-is-not-configured-to-tf3757780.html#a10724278
>> Sent from the ARS (Action Request System) mailing list archive at
>> Nabble.com.
>>
>>
>>
_______________________________________________________________________________
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.orgARSlist:"Where
>> the Answers Are"
>>
>
>
_______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
> the Answers Are"
>
>
--
View this message in context:
http://www.nabble.com/Midtier-using-RPC-but-ars-is-not-configured-to-tf3757780.html#a10778986
Sent from the ARS (Action Request System) mailing list archive at
Nabble.com.
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers
Are"
