Good info for me to pass to the unix/network guys. Regarding the port, I don't think so ... we use dns so we remsrv (prod) and remsrvtest (test) to connect. They both use port 55855. Could that be an issue?
Thanks, Susan On Tue, Jun 30, 2009 at 10:59 AM, Axton <[email protected]> wrote: > ** I do not see how the IP-Name parameters would apply to this situation. > In your case, I would check the following things: > - session timeout configured on the bigip devices (should match that of > arserver) > - session timeout configured for any firewall devices that are in your path > (should match bigip and ar) > - persistent session sessions on the bigip device (should always redirect > user to same node for session period) > > The arservers do not act as a load balancing cluster, but instead act as an > ha cluster. When you connect to the cluster, you should ensure that you are > connecting to the proper node for certain (e.g., admin) operations. General > operations (fast/list) can be accommodated by any node, but you have to make > sure you talk to the same node for your entire session. If the bigip device > redirects your session from one node to a different node, I would expect to > see the rpcbind errors. > > When you say they are both using the same port, are you using the same > hostname/ip to access both? If so, this could be an issue. > > Axton Grams > > The opinions, statements, and/or suggested courses of action expressed in > this E-mail do not necessarily reflect those of BMC Software, Inc. My > voluntary participation in this forum is not intended to convey a role as a > spokesperson, liaison or public relations representative for BMC Software, > Inc. > > On Tue, Jun 30, 2009 at 10:05 AM, Susan Palmer <[email protected]>wrote: > >> ** >> Hi Axton, >> >> We just recently moved from windows to unix (sun solaris 10) and the >> servers are behind a bigip at a remote location. We split the database onto >> a separate server. We had no problems with the production server since we >> put the old prod name in the bigip and everyone is able to connect by simply >> adding a port id (6/13/09). >> >> But now that we brought up the test server I have been getting rpcbind >> errors which are even affecting both test and prod servers for ME only. I'm >> the only one that has logged into both servers so that is not surprising. I >> can get logged in and do a little work on test and then if my PC is idle for >> a while the next access on that server gives the 90 rpcbind error. Same >> thing can happen on prod. Now I don't log into test if I'm logged into prod >> and vice/versa. >> >> Do you think adding the line to ar.conf >> >> IP-Name: remsrvtest >> >> will help alleviate the issue? We do use dns. On the test server the >> 'remsrvtest' is on the bigip (the actual server name is remztapp01). Prod >> is 'remsrv'. They both use the same port (could that be an issue). >> >> This is driving me crazy and support hasn't found anything either. >> >> We just did the prod move on 6/13 and brought up the test server 6/23. >> Since we brought up that test server my life has been misery. I haven't >> even been able to clean the server references (since we copied the prod >> db). We are blessed with old HDv5.0 workflow which loved to embed server >> names that even replacement doesn't remove. There is always manual >> cleanup. But even just trying to import the forms only times out giving me >> the rpcbind error. I've never had a rpcbind error ever. >> >> We don't have an issue with dev since it's at our location not behind a >> bigip. >> >> Any suggestions would be greatly appreciated. >> >> Thanks, >> Susan >> >> Unix Sun Solaris 10 >> ARS 7.0.1P2 >> Oracle 10g (and it is somewhat disappointing I don't think I can blame >> this on oracle ... :) ) >> >> Susan Palmer >> >> Enterprise Remedy Developer and Administrator >> >> ShopperTrak RCT Corporation >> >> 200 W Monroe St 11th Floor >> >> Chicago, IL 60606 >> >> Office 312-529-5325 >> >> Cell 312-502-7687 >> >> >> On Mon, Jun 29, 2009 at 7:38 PM, Axton <[email protected]> wrote: >> >>> ** I believe this can still be an issue even in later versions >>> depending on how the server is configured. Say the hostname of the arserver >>> host is remedy1, it has ip address 10.1.1.1 and the following dns aliases: >>> >>> remedy >>> remedy.company.com >>> ars >>> ars.company.com >>> >>> Let's say the Server-Name parameter in ar.conf has a value of remedy1. >>> >>> If you connect using the admin tool to the arserver with a hostname of >>> remedy, that name will be embedded in the workflow unless you have >>> configured the proper IP-Name parameters in ar.conf. The valid IP-Name >>> parameters would be any hostname with which arserver can be accessed, so you >>> would want the following lines in ar.conf: >>> >>> IP-Name: remedy >>> IP-Name: remedy.company.com >>> IP-Name: ars >>> IP-Name: ars.company.com >>> >>> This problem is more common with arsystem configurations where multiple >>> arservers are in use. Take the following example: >>> >>> hostname for arserver1: remedy01 (10.0.0.1) >>> hostname for arserver2: remedy02 (10.0.0.2) >>> hostname for arserver3: remedy03 (10.0.0.3) >>> >>> hostname for load balancer: remedy (10.1.0.1) >>> Aliases/other names for load balancer: arsystem, arsystem.company.com >>> Aliases/other names for remedy01: arsvr01, arsvr01.company.com, >>> remedy01.company.com >>> Aliases/other names for remedy02: arsvr02, arsvr02.company.com, >>> remedy02.company.com >>> Aliases/other names for remedy03: arsvr03, arsvr03.company.com, >>> remedy03.company.com >>> >>> You could now potentially access each arserver using several names >>> (strings). The ar.conf (IP-Name parameters) needs to be different on each >>> arserver. >>> >>> The IP-Name parameter seems to be used to parse the workflow when >>> committing workflow to the db; it is used to strip server name references >>> and replace them with the desired @ symbol (global local server reference). >>> If no match is found to Server-Name or IP-Name, the workflow will think the >>> reference is to and external ARServer and store the actual name of the >>> server in the workflow when written to the db. >>> >>> Axton Grams >>> >>> These are my opinions and observations. >>> >>> >>> On Mon, Jun 29, 2009 at 5:51 PM, Shellman, David< >>> [email protected]> wrote: >>> > Lee, >>> > >>> > The 4.x versions and 5.x versions were a bugger with retaining server >>> and IP >>> > address information. There were scripts that could be run against def >>> files >>> > to clean up remainder of server info that remained in the files. Menus >>> were >>> > the worst offenders. >>> > >>> > I don't remember any issues with exporting as server independent with >>> 6.x >>> > nor have I seen any with 7.0.1. >>> > Dave >>> > ------------------------- >>> > [email protected] >>> > (Wireless) >>> > >>> > ________________________________ >>> > From: Action Request System d_Platinum Sponsor: >>> [email protected] ARSlist: "Where the Answers Are"_ >>> >> > _Platinum Sponsor: [email protected] ARSlist: "Where the Answers > Are"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
