Workflow Login Error

[#1]

Hello all,I've just installed the Workflow Snapin and updated the /portal/Snapin-workflow/cgi-bin/WebConfig.pm file with my environment information (devserver, username, password and gridname).However, I'm receiving a login error when I run the snapin:"Error with sudo, the account in WebConfig.pm: Server 172.16.152.100 is not responding" (172.16.152.100 is my DDI Box)Could anybody help me with this issue? There are no reference to sudo user in my WebConfig.pm:devserver => "172.16.152.100"username => "admin"password => "infoblox"gridname => "Infoblox"Best regards,Alfonso Moneo

[#2]

Hey amoneo,

Quick comment from one of our internal folks:

Is .100  your Grid Master IP Address or your bloxTools member's IP Address? It will need to be the GM for it to work. Just a thought…

Eric

[#3]

Hello Eric,172.16.152.100 is my Grid Master IP Address...Alfonso

[#4]

Is there any chance there are firewall rules that might prevent connecting to the gridserver? They error "is not responding" implies that either the packets aren't getting through or that the service on the gridmaster isn't turned on. 

[#5]

I'm not trying to hijack Alfonso's thread, but I, too, am having the same issue with workflow.Details on my configurtaion:Running tools Out-Of-Grid on ubuntu server 11.04 w/mod-perl 2.0.4, Perl 5.10.1.I installed the ubuntu packages based off the post (http://troels.info/blog/wiki/InstallInfobloxUbuntu) http://www.infoblox.com/community/forum/bloxtools/environments/how-install-infobloxbloxtools-ubuntu-... . In the webserver error logs, I get no errors at this point (logs bumped up to debug trying to figure this out). If I login with the userid that is listed in the WebConfig.pm, it allows me to login, but it complains saying the IP address isn't responding. The ubuntu server & GM are both on the same /24, with no firewall between. The grid security settings allow for that /24 to access the gui/api. I *am* able to run api scripts from the server with no issues using the same login information. One of the specific errors I see is: Combofield Error: templateThe setup isn't allowing me to run the init.pl script. It gives the same GM-IP not responding on every attempt to connect.

[#6]

Hijack away.

I'm not sure what is going on here. It's possible something is not set up so that it's connecting to the correct machine, or the server isn't running so it's not there to receive the request. I can't find any history on problems like this that might help point me at a solution, but I'm going to dig into it a bit deeper today.

[#7]

If you would like to do some sort of shared-session/desktop sharing, I'd be game so you could see it first hand if you'd like.

[#8]

Was there any resolution to this issue? I have run into the same problem. Running Redhat 5.8 here. It seems like Simple.pm is not creating the session with the grid master. No firewalls in the way here either. I am able to run native API calls from this machine. p.s. If someone from Infoblox support wants to do desktop sharing, I'm all for helping the community.

[#9]

3 different systems. It looks like the same problem, it probably isn't.

amoneo:

If bloxtools is running on an appliance, you may have a timeout error related to not enough ram or old harware. Try bumping the ram to 515m in the bloxtools config, and make sure you are running on a 155-A or newer model HW

jshafer & craqed :

Since you are using a local dev server, you are probably hitting an SSL error. The scripts are failing on your HTTPs cert validation. either disable HTTPs (just use HTTP:80) or you need to add the following line to Simple.pm:

'$ENV{PERL_LWP_SSL_VERIFY_HOSTNAME}=0;'

[#10]

Is there a way to enable a debug mode to write out logs on the server to watch what is going on (at the API level)? I see the test account logging in now and see the populated zone drop-downs etc. But I am getting the same error when I try to submit a change. update:I changed the system Simple.pm within the LWP package (dedicated vm guest for this purpose....) and am able to login as I should and see a good bit of data as I would expect to see. I tried to submit an immediate change and it came back with an error of "The action is not allowed. A parent was not found.". I am suspecting that it is trying to work on the wrong DNS or Network View even though I set it in WebConfig.pm for the default view to use. Is it possible to have the view to submit changes in being a select box?

[#11]

I just noticed an error that is flashing by on the "popup" quickly that might be related to the view issue, "Combofield : View Server: IPadddress not responding"

[#12]

Editing Simple.pm is not recommended. I'd want to see what you changed before I could offer any good advice.There isn't a debug mode that will log anything useful, almost all errors should get propogated back to the browser. If you have a javascript debugger (like firebug) you should look at the individual AJAX calls and see what gets returned.the 'parent was not found' error does imply you have the wrong view, but I don't know what object you were trying to add so i don't know what view you need to set/override.you can also add a 'view' select box, it just requires customisation of the dialogs, you should check the customisation guide for details on this

[#13]

This error means that the system wasn't able to contact NIOS and get the list of views to populate the 'views' combofield.so it all goes back to the 'logins not creating a valid session' problemUnfortunately, the errors can sometimes clobber each other in the alert window, so the last error you see is isnt always the most useful one (this is where the 'A' in 'AJAX' becomes a problem)and, if this is running on a dev box (*and not a infoblox appliance) debugging this is going to be hard, and hard to reproduce.one thing you can try and test is just the login component: /workflow/cgi-bin/auth.pl?username=admin&password=xxxThis might help narrow down the problem, But we've seen in the past that calling auth.pl directly seems to work but calling it from the webpage doesn't. The last time we encountered this, it was a global timeout error due to the web server not having enough RAM. (all the AJAX calls overloaded the webserver)

[#14]

I had edited the Simple.pm to test the ssl_verify mentioned above. When it didn't make a difference in the responses I was getting, I took the line back out. I'll check into firebug and see what I'm getting.

[#15]

Using firebug I have noticed that when no_auth is commented out (in WebConfig.pm, requiring auth) views-list.pl consistantly fails every single time with "Server XXX is not responding", while all others seem to populate normally (occasionally, others will fail also, but it's not consistant like views-list.pl)