I'm having trouble to install the bloxconsole. After I upload the directory bloxconsole/ and the file conf/snapins/bloxconsole.conf to the VIP 146.191.241.190 following the installation instructions, restart the bloxtools environment and browse to https://146.191.241.190:444/bloxconsole/workflow/, I get in IE
and then it just hangs. I've even restarted the gridmaster, but it made no difference. Any ideas?
Thanks
Where did you install your htdocs-workflow directory? It must be installed off of the root and not in the htdocs directory. This could be the issue.Also, are you able to access the toolkit (/bloxconsole/wat)?
This could be a Cariage Return/Linefeed (CR/LF) issue. This can happen if one of the tools you used to unpack and upload the snapin files changed the files from "Unix files" to "Windows/DOS files". Try removing the snapin from your bloxTools Environment and installing it again using a tool that preserves the file format. Don't forget the conf file. Take a look at the following blog on the topic:
https://www.bloxtools.com/blogs/tool_time/archive/2008/09/15/ftp-bloxtools-and-you.aspx
By the way, restarting the bloxTools Environment is enough to reset it. You should not have to restart your grid master.
It was installed to the root. After few restarts of the service I got it "working" to some extend - very slow responses and memory leaks. Then it stopped working altogether - even if I deleted the files and reinstalled again. I'm getting the same error again. The /bloxconsole/wat "worked" similarly for a short time - the widgets didn't recognize my zones (even in default view)
I used Filezilla FTP, transfer method = auto.
It looks as if the web server doesn't properly.
What HW platform and what SW version are you running?
HW is IB-1050 and SW is 4.3r2-4-47610
That is the same version of NIOS I run on my IB-1000s. So, we can rule out the hardware/OS as the source of your problem. Let's take a closer look at your configuration.
Personally, I configure FileZilla to use binary mode, because that is the only way to ensure you will put an exact copy of your files in the bloxTools environment.
Next, it sounds like you got bloxConsole to run for a little bit. Have you checked the error.log file for errors?
As for performance, how many objects are you manipulating? In my experience bloxConsole is pretty usable. Ultimately, any snapin can only be as responsive as the Perl API (DMAPI) on which it relies.
Also, keep in mind that WAT is not intended to do anything useful. WAT is a widgets and sample code library you may use to build your own snapin. Think of the WAT snapin as a widget "gallery" where you can get a feel for what's available and how things work.
Finally, we have seen the memory exhaustion problem before. If you do exhaust the available memory, your snapin will stop running. We are testing a fix for the memory usage issue. In the mean time, restarting the bloxTools Environment will release the memory.
I've republished the files using Filezilla in binary mode - it made no difference.
The only relevant record in the syslog is the occassional
Type: BloxTools Environment State: Red Event: Invalid Trap Number Received
It's a test environment so I haven't got too many objects in DNS.
Perhaps I should say in IE there is always the common notice about the certificate (the site name doesn't match and I cannot find out for which name the certificate was issued). If I proceed I get the text I started this thread with and then it hangs. I got it "working" (very slow) for a while possibly by editing webconfig.pm file (setting up master IP, user, password and gridname) - this is not in the installation instructions, though.
OK. So now we are pretty sure your uploaded files are in order. The next step is to take a closer look at the bloxTools Environment logs. Please have a look at the bloxTools Environment trouble shooting blog for details:
I cannot see anything obviously alarming in the log files.
In the eeror log
[Mon Jan 12 13:24:31 2009] [warn] RSA server certificate CommonName (CN) `www.infoblox.com' does NOT match server name!?
[Mon Jan 12 13:24:33 2009] [notice] Digest: generating secret for digest authentication ...
[Mon Jan 12 13:24:33 2009] [notice] Digest: done
[Mon Jan 12 13:24:34 2009] [warn] RSA server certificate CommonName (CN) `www.infoblox.com' does NOT match server name!?
[Mon Jan 12 13:24:34 2009] [notice] Apache/2.2.6 (Unix) mod_ssl/2.2.6 @E\n\nSSL/\xb0\x1aE@|YQ@ DAV/2 mod_perl/2.0.3 Perl/v5.8.8 configured -- resuming normal operations
and in the syslog
Jan 14 16:55:01 data-centre /usr/sbin/cron[15328]: (root) CMD (/etc/run_apache.sh)
Jan 14 16:55:01 data-centre /usr/sbin/cron[15330]: (root) CMD (/etc/portal_monitor.sh)
Jan 14 16:55:01 data-centre /usr/sbin/cron[15332]: (root) CMD (/etc/vsftpd.pm)
Restartng the bloxTools service is strange - it takes ages and the only way for me to see it is refreshing the status of the service.
Has there been any headway to this issue.
I am having the same problem.
Any help will be greatly appreciated.
Dave
**The Scoop**
I use WS_FTP Pro
FTPed bloxconsole directiry to /
bloxconsole.conf to /conf/snapins
HW IB-1200
SW 4.3r2-4-47610
**If I go to either**
https://172.21.252.10:444/bloxconsole/workflow/
https://172.21.252.10:444/bloxconsole/wat/
**This is what I see **
SSL/°E@|YQ@ DAV/2 mod_perl/2.0.3 Perl/v5.8.8 Last-Modified: Fri, 30 Jan 2009 15:23:57 GMT ETag: "f2307-4e6-cb243d40" Accept-Ranges: bytes Content-Length: 1254 Keep-Alive: timeout=600 Connection: Keep-Alive Content-Type: text/html
**logs from the CLI**
Infoblox > show file bloxtools portal_access
Showing file /storage/web-portal/udata/logs/access.log
----------------------------------------
172.23.9.1 - - [30/Jan/2009:10:29:20 -0500] "GET /bloxconsole/wat/ HTTP/1.1" 200 1254
172.23.9.1 - - [30/Jan/2009:10:29:20 -0500] "GET /bloxconsole/wat/ext/ext-base.js HTTP/1.1" 200 35666
172.23.9.1 - - [30/Jan/2009:10:29:56 -0500] "GET /bloxconsole/workflow/ HTTP/1.1" 200 1530
Enter <return> to continue with More lines or enter q<return> to proceed to the next file
172.23.9.1 - - [30/Jan/2009:10:29:56 -0500] "GET /bloxconsole/workflow/ext/ext-base.js HTTP/1.1" 200 35666
172.23.9.1 - - [30/Jan/2009:10:31:50 -0500] "GET /bloxconsole/workflow/ HTTP/1.1" 200 1530
172.23.9.1 - - [30/Jan/2009:10:31:50 -0500] "GET /bloxconsole/workflow/ext/ext-base.js HTTP/1.1" 200 35666
172.23.9.1 - - [30/Jan/2009:10:32:19 -0500] "GET /bloxconsole/workflow/ HTTP/1.1" 200 1530
172.23.9.1 - - [30/Jan/2009:10:36:31 -0500] "GET /bloxconsole/wat/ HTTP/1.1" 200 1254
172.23.9.1 - - [30/Jan/2009:10:36:31 -0500] "GET /bloxconsole/wat/ext/ext-base.js HTTP/1.1" 200 35666
172.23.9.1 - - [30/Jan/2009:10:37:44 -0500] "GET /bloxconsole/wat/ HTTP/1.1" 200 1254
172.23.9.1 - - [30/Jan/2009:10:37:44 -0500] "GET /bloxconsole/wat/ext/ext-base.js HTTP/1.1" 200 35666
**status**
show bloxtools
bloxTools status: enabled(GREEN)
CPU: 5%, Memory: 28%, Hard Disk: 1%
r eferer: https://llb-pri-dns:444/
Infoblox > show file bloxtools portal_log
Showing file /storage/web-portal/udata/logs/syslog.log
----------------------------------------
Jan 28 07:36:56 (none) kernel: Linux version 2.6.17.4 (root@buildvm14-aslan) (gcc version 3.2.1) #1 Thu Dec 4 16:59:39 EST 2008
Jan 28 07:36:56 (none) kernel: On node 0 totalpages: 32768
Jan 28 07:36:56 (none) kernel: DMA zone: 32768 pages, LIFO batch:7
Jan 28 07:36:56 (none) kernel: Built 1 zonelists
Jan 28 07:36:56 (none) kernel: Kernel command line: root=/dev/root rootfstype=hostfs rootflags=/storage/web-portal/root_fs ubdb=/storage/web-portal/swapfile ubdc=/storage/web-portal/storagefile mem=128M eth0=tuntap,uml_htap0 con0=null con1=pts con2=pts hostfs=/storage/web-portal
Jan 28 07:36:56 (none) kernel: PID hash table entries: 1024 (order: 10, 4096 bytes)
Jan 28 07:36:56 (none) kernel: Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Jan 28 07:36:56 (none) kernel: Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Jan 28 07:36:56 (none) kernel: Memory: 124372k available
Jan 28 07:36:56 (none) kernel: Calibrating delay loop... 2077.49 BogoMIPS (lpj=10387456)
Jan 28 07:36:56 (none) syslog-ng[699]: syslog-ng starting up; version='2.0.6'
Jan 28 07:36:56 (none) kernel: Mount-cache hash table entries: 512
Jan 28 07:36:56 (none) kernel: Checking for host processor cmov support...Yes
Jan 28 07:36:56 (none) kernel: Checking for host processor xmm support...No
Jan 28 07:36:56 (none) kernel: Checking that host ptys support output SIGIO...Yes
Jan 28 07:36:56 (none) kernel: Checking that host ptys support SIGIO on close...No, enabling workaround
Jan 28 07:36:56 (none) kernel: Using 2.6 host AIO
Jan 28 07:36:56 (none) kernel: NET: Registered protocol family 16
Jan 28 07:36:56 (none) kernel: NET: Registered protocol family 2
Jan 28 07:36:56 (none) kernel: IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
Jan 28 07:36:56 (none) kernel: TCP established hash table entries: 4096 (order: 2, 16384 bytes)
the portal_error log is the one we want to see. if the web server can't render the html corretly it will log something in the error log.
it still seems like the files were uploaded in BINARY mode, when it should have been ASCII.
Thanks for your reply
Here is the error log
[Fri Jan 30 10:29:11 2009] [notice] Digest: done
[Fri Jan 30 10:29:12 2009] [warn] RSA server certificate CommonName (CN) `pri-dns' does NOT match server name!?
[Fri Jan 30 10:29:12 2009] [notice] Apache/2.2.6 (Unix) mod_ssl/2.2.6 @E\n\nSSL/\xb0\x1aE@|YQ@ DAV/2 mod_perl/2.0.3 Perl/v5.8.8 configured -- resuming normal operations
I deleted the files I had FTPed up and FTPed up new files making sure I used Binary mode.
I get eh same results when using IE
If I use Fire fox I get a pop up saying I have chosen to open a application/octet-stream and asks what to do with the file.
FTP in ASCII mode ( NOT binary mode )
Sorry the files have been FTPed in ASCII to root
same issues IE I get the
SSL/°E@|YQ@ DAV/2 mod_perl/2.0.3 Perl/v5.8.8 Last-Modified: Mon, 02 Feb 2009 20:48:17 GMT ETag: "f29d1-5cd-ac926640" Accept-Ranges: bytes Content-Length: 1485 Keep-Alive: timeout=600 Connection: Keep-Alive Content-Type: text/html
Firefox wants to load a file
Still not working for me either. The files have been ftped OK.
Here is my output of portal_log after restarting bloxtools environment and attempting to view .../bloxconsole/wat:
Feb 3 13:48:48 (none) kernel: Linux version 2.6.17.4 (root@buildvm14-aslan) (gcc version 3.2.1) #1 Thu Dec 4 16:59:39 EST 2008
Feb 3 13:48:48 (none) kernel: On node 0 totalpages: 32768
Feb 3 13:48:48 (none) kernel: DMA zone: 32768 pages, LIFO batch:7
Feb 3 13:48:48 (none) kernel: Built 1 zonelists
Feb 3 13:48:48 (none) kernel: Kernel command line: root=/dev/root rootfstype=hostfs rootflags=/storage/web-portal/root_fs ubdb=/storage/web-portal/swapfile ubdc=/storage/web-portal/storagefile mem=128M eth0=tuntap,uml_htap0 con0=null con1=pts con2=pts hostfs=/storage/web-portal
Feb 3 13:48:48 (none) kernel: PID hash table entries: 1024 (order: 10, 4096 bytes)
Feb 3 13:48:48 (none) kernel: Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Feb 3 13:48:48 (none) kernel: Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Feb 3 13:48:48 (none) kernel: Memory: 124372k available
Feb 3 13:48:48 (none) kernel: Calibrating delay loop... 6697.77 BogoMIPS (lpj=33488896)
Feb 3 13:48:48 (none) syslog-ng[699]: syslog-ng starting up; version='2.0.6'
Enter <return> to continue with More lines or enter q<return> to proceed to the next file
Feb 3 13:48:48 (none) kernel: Mount-cache hash table entries: 512
Feb 3 13:48:48 (none) kernel: Checking for host processor cmov support...Yes
Feb 3 13:48:48 (none) kernel: Checking for host processor xmm support...No
Feb 3 13:48:48 (none) kernel: Checking that host ptys support output SIGIO...Yes
Feb 3 13:48:48 (none) kernel: Checking that host ptys support SIGIO on close...No, enabling workaround
Feb 3 13:48:48 (none) kernel: Using 2.6 host AIO
Feb 3 13:48:48 (none) kernel: NET: Registered protocol family 16
Feb 3 13:48:48 (none) kernel: NET: Registered protocol family 2
Feb 3 13:48:48 (none) kernel: IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
Feb 3 13:48:48 (none) kernel: TCP established hash table entries: 4096 (order: 2, 16384 bytes)
Feb 3 13:48:48 (none) kernel: TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
Feb 3 13:48:48 (none) kernel: TCP: Hash tables configured (established 4096 bind 2048)
Feb 3 13:48:48 (none) kernel: TCP reno registered
Feb 3 13:48:48 (none) kernel: Checking host MADV_REMOVE support...MADV_REMOVE failed, err = -38
Feb 3 13:48:48 (none) kernel: Can't release memory to the host - memory hotplug won't be supported
Feb 3 13:48:48 (none) kernel: mconsole (version 2) initialized on /root/.uml/web-portal/mconsole
Feb 3 13:48:48 (none) kernel: UML Watchdog Timer
Feb 3 13:48:48 (none) kernel: Netdevice 0 : TUN/TAP backend -
Feb 3 13:48:48 (none) kernel: Host TLS support detected
Feb 3 13:48:48 (none) kernel: Detected host type: i386
Enter <return> to continue with More lines or enter q<return> to proceed to the next file
Feb 3 13:48:48 (none) kernel: VFS: Disk quotas dquot_6.5.1
Feb 3 13:48:48 (none) kernel: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Feb 3 13:48:48 (none) kernel: fuse init (API version 7.6)
Feb 3 13:48:48 (none) kernel: Initializing Cryptographic API
Feb 3 13:48:48 (none) kernel: io scheduler noop registered
Feb 3 13:48:48 (none) kernel: io scheduler anticipatory registered (default)
Feb 3 13:48:48 (none) kernel: io scheduler deadline registered
Feb 3 13:48:48 (none) kernel: io scheduler cfq registered
Feb 3 13:48:48 (none) kernel: RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Feb 3 13:48:48 (none) kernel: loop: loaded (max 8 devices)
Feb 3 13:48:48 (none) kernel: PPP generic driver version 2.4.2
Feb 3 13:48:48 (none) kernel: tun: Universal TUN/TAP device driver, 1.6
Feb 3 13:48:48 (none) kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Feb 3 13:48:48 (none) kernel: Netfilter messages via NETLINK v0.30.
Feb 3 13:48:48 (none) kernel: IPv4 over IPv4 tunneling driver
Feb 3 13:48:48 (none) kernel: GRE over IPv4 tunneling driver
Feb 3 13:48:48 (none) kernel: ip_conntrack version 2.4 (972 buckets, 7776 max) - 224 bytes per conntrack
Feb 3 13:48:48 (none) kernel: ctnetlink v0.90: registering with nfnetlink.
Feb 3 13:48:48 (none) kernel: ip_conntrack_pptp version 3.1 loaded
Feb 3 13:48:48 (none) kernel: ip_nat_pptp version 3.0 loaded
Enter <return> to continue with More lines or enter q<return> to proceed to the next file
Feb 3 13:48:48 (none) kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
Feb 3 13:48:48 (none) kernel: ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>. http://snowman.net/projects/ipt_recent/
Feb 3 13:48:48 (none) kernel: ClusterIP Version 0.8 loaded successfully
Feb 3 13:48:48 (none) kernel: arp_tables: (C) 2002 David S. Miller
Feb 3 13:48:48 (none) kernel: TCP bic registered
Feb 3 13:48:48 (none) kernel: NET: Registered protocol family 1
Feb 3 13:48:48 (none) kernel: NET: Registered protocol family 10
Feb 3 13:48:48 (none) kernel: lo: Disabled Privacy Extensions
Feb 3 13:48:48 (none) kernel: IPv6 over IPv4 tunneling driver
Feb 3 13:48:48 (none) kernel: ip6_tables: (C) 2000-2006 Netfilter Core Team
Feb 3 13:48:48 (none) kernel: NET: Registered protocol family 17
Feb 3 13:48:48 (none) kernel: NET: Registered protocol family 15
Feb 3 13:48:48 (none) kernel: Bridge firewalling registered
Feb 3 13:48:48 (none) kernel: 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
Feb 3 13:48:48 (none) kernel: All bugs added by David S. Miller <davem@redhat.com>
Feb 3 13:48:48 (none) kernel: Initialized stdio console driver
Feb 3 13:48:48 (none) kernel: Console initialized on /dev/tty0
Feb 3 13:48:48 (none) kernel: Initializing software serial port version 1
Feb 3 13:48:48 (none) kernel: Failed to open 'root_fs', errno = 2
Feb 3 13:48:48 (none) kernel: ubdb: unknown partition table
Enter <return> to continue with More lines or enter q<return> to proceed to the next file
Feb 3 13:48:48 (none) kernel: ubdc: unknown partition table
Feb 3 13:48:48 (none) kernel: VFS: Mounted root (hostfs filesystem) readonly.
Feb 3 13:48:48 (none) kernel: line_ioctl: tty0: ioctl KDSIGACCEPT called
Feb 3 13:48:48 (none) kernel: (fs/jbd/recovery.c, 255): journal_recover: JBD: recovery, exit status 0, recovered transactions 41089 to 41527
Feb 3 13:48:48 (none) kernel: (fs/jbd/recovery.c, 257): journal_recover: JBD: Replayed 876 and revoked 0/0 blocks
Feb 3 13:48:48 (none) kernel: kjournald starting. Commit interval 5 seconds
Feb 3 13:48:48 (none) kernel: EXT3 FS on ubdc, internal journal
Feb 3 13:48:48 (none) kernel: EXT3-fs: recovery complete.
Feb 3 13:48:48 (none) kernel: EXT3-fs: mounted filesystem with ordered data mode.
Feb 3 13:48:48 (none) init: Entering runlevel: 3
Feb 3 13:48:49 (none) kernel: Adding 524280k swap on /dev/ubdb. Priority:-1 extents:1 across:524280k
Feb 3 13:48:52 (none) crontab[740]: (root) LIST (root)
Feb 3 13:48:52 (none) crontab[741]: (root) REPLACE (root)
Feb 3 13:48:52 (none) crontab[742]: (root) REPLACE (root)
Feb 3 13:48:52 (none) crontab[743]: (root) REPLACE (root)
Feb 3 13:48:52 (none) crontab[744]: (root) REPLACE (root)
Feb 3 13:48:55 (none) /usr/sbin/cron[798]: (CRON) STARTUP (V5.0)
Feb 3 13:48:55 (none) /usr/sbin/cron[798]: (*system*) BAD FILE MODE (/etc/crontab)
Feb 3 13:48:55 (none) /usr/sbin/cron[798]: (*system*) BAD FILE MODE (/etc/cron.d/cron.allow)
Feb 3 13:48:55 (none) kernel: Virtual console 1 assigned device '/dev/pts/0'
Enter <return> to continue with More lines or enter q<return> to proceed to the next file
Feb 3 13:48:55 (none) kernel: Virtual console 2 assigned device '/dev/pts/1'
Feb 3 13:48:59 (none) kernel: eth0: no IPv6 routers present
Feb 3 13:49:01 (none) /usr/sbin/cron[803]: (root) CMD (/etc/run_apache.sh)
Feb 3 13:49:01 (none) /usr/sbin/cron[805]: (root) CMD (/etc/portal_monitor.sh)
Feb 3 13:49:01 (none) /usr/sbin/cron[807]: (root) CMD (/etc/vsftpd.pm)
Feb 3 13:50:01 (none) /usr/sbin/cron[882]: (root) CMD (/etc/run_apache.sh)
Feb 3 13:50:01 (none) /usr/sbin/cron[884]: (root) CMD (/etc/portal_monitor.sh)
Feb 3 13:50:01 (none) /usr/sbin/cron[886]: (root) CMD (/etc/vsftpd.pm)
Feb 3 13:50:01 (none) /usr/sbin/cron[888]: (root) CMD (/usr/sbin/logrotate /etc/logrotate.conf)
Feb 3 13:51:01 (none) /usr/sbin/cron[966]: (root) CMD (/etc/run_apache.sh)
Feb 3 13:51:01 (none) /usr/sbin/cron[968]: (root) CMD (/etc/portal_monitor.sh)
Feb 3 13:51:02 (none) /usr/sbin/cron[970]: (root) CMD (/etc/vsftpd.pm)
Feb 3 13:52:01 (none) /usr/sbin/cron[1046]: (root) CMD (/etc/run_apache.sh)
Feb 3 13:52:01 (none) /usr/sbin/cron[1048]: (root) CMD (/etc/portal_monitor.sh)
Feb 3 13:52:01 (none) /usr/sbin/cron[1050]: (root) CMD (/etc/vsftpd.pm)
Infoblox >
Hi, I'm new here. Not running my 1050's in production just yet, but soon. Ftpd is chmod'ing all the files to 777. Is it meant to be like this ? I have the same error and the same symptoms as the others here (execpt I cant get it working at all). Latest software 4.3r2.
Regards, Sander
We are now able to get a log in screen I wish I could tell you what was done to make this happen but I am unsure. I had loaded the bloxtools tree up to root removed it and uploaded it again using filezilla (which I really like by the way). After restarts of the bloxtools environment we still had the odd page loading (see above post) I loaded up the new BDK and still had the same issue. Yesterday I was on a call with our SE and he had me brose to the login page and everything worked.... go figure.
Thanks to all for your imput
Hi Dave,
Did we get this resolved? If so could you post a follow up for the other members?
thanks!
It has been resolved. As I said in the prior post I wish I knew why it is working now. The only thing I had done was load the new BDK. I hadn't done anything else to try to get it to work. and when our SE and I had the time we hooked up and I brought up the page to show him the error message we were getting. Instead of the message I got a log on screen and was able to log in.
i know that isn't any help to the others that are having this problem I wish I could figure out what the issue was.
hmm, maybe when you uploaded the new BDK a change to the /conf/snapins/bloxconsole.conf was picked up (however, a restart of the environment would have been necessary for this to happen)
Sheer speculation on my part.....
Hmmmm well hard saying not know'n but I did restart the enviroment after I loaded the BDK.
Yep, so the new BDK has modifications in the conf file and a restart would have definitely picked them up, so it may be a simple case of the restart with the new conf file fixing it. We have seen a few spats of weirdness with FTP'ing content but they are usually earmarked with 'permission' errors or 'execution' errors in the error log.
Please post any additional findings!
Thanks Dave!
