So one of the things that you probably ought not do is to link directly to a script on github or another development service, especially not directly to someone’s webiste.
In our internal corporate employee site, the devs have used a jQuery Easing plugin by George Smith Graphic Design in the UK. Apparently they missed the notice on his plugin website about using a real CDN instead of hotlinking to the script on his site.
And even though they ignored that, you would think they would have seen the banner that comes up on the internal site itself.
So you have a RedHat/CentOS host that has just been handed off to you. The host has been configured by the previous admin to mount some storage from a SAN. How do you find out what is mapped where?
Normally to determine what is mapped where and the relevant usage you could use:
This would give you something like the following output:
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 233G 98G 124G 45% /
/dev/sda1 251M 46M 193M 20% /boot
tmpfs 48G 0 48G 0% /dev/shm
/dev/mapper/datasan_vg-datasan_lv 1.0T 218G 807G 22% /datasan
/dev/mapper/pglog_vg-pglog_lv 300G 193G 108G 65% /pglog
10.30.197.250:/vol/onesc_pglog/pg_dumps 238G 223G 15G 94% /backups/pg_dumps
10.30.197.250:/vol/onesc_pglog/pitr_backup 238G 223G 15G 94% /backups/pitr_backup
That’s all well and good. It shows you that you have two logical volumes datasan and pglog that are mounted on the root, but what if you needed to know more about those volumes?
To get more info on the volume groups, use the vgdisplay command:
— Volume group — VG Name pglog_vg System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 11 VG Access read/write VG Status resizable Clustered yes Shared no MAX LV 0 Cur LV 1 Open LV 1 Max PV 0 Cur PV 1 Act PV 1 VG Size 299.99 GB PE Size 4.00 MB Total PE 76798 Alloc PE / Size 76797 / 299.99 GB Free PE / Size 1 / 4.00 MB
VG UUID SrVfEk-e5fx-0x0i-WhXb-uqsM-Uh5S-FDcNeP
— Logical volume — LV Name /dev/pglog_vg/pglog_lv VG Name pglog_vg LV UUID wZBCcO-jGWW-LdkQ-Mbhl-Et8a-1sqC-5Ednj5 LV Write Access read/write LV Status available # open 1 LV Size 299.99 GB Current LE 76797 Segments 1 Allocation inherit Read ahead sectors auto – currently set to 256
— Segments — Logical extent 0 to 76796: Type linear Physical volume /dev/mpath/pglogp1
Physical extents 0 to 76796
Now that you know the physical volume(s) in the logical volume you can find out some details on the physical volume itself:
— Physical volume — PV Name /dev/mpath/pglogp1 VG Name pglog_vg PV Size 300.00 GB / not usable 4.03 MB Allocatable yes PE Size (KByte) 4096 Total PE 76798 Free PE 1 Allocated PE 76797
PV UUID CwxWYc-SjKX-KvPj-vJoq-i4dZ-2jzm-rHGNd1
Today while working on the AASU Blackboard VISTA custom login page, I ran into an issue loading Java applets.
Apparently, Google Chrome checks your browser plug-ins to determine if they are out of date when you attempt to load content requiring them. Here’s a snippet from the Google Support Site about the bug feature:
To make sure you’re protected, whenever Google Chrome detects that a common plug-in on a page is out of date with a security vulnerability, a message will appear beneath the address bar notifying you that the plug-in has been blocked.
While this is a great feature, since it is an attempt to protect your computer from nefarious code, there are times that it just doesn’t work properly.
The situation I ran into is described on a chromium issue report. Basically, the Linux version of Oracle Java 7 is being seen as out-of-date, even though it is the most recent version available. When going into the Google Chrome plug-in preferences you may see the Java plug-in marked as disabled and showing the version number in red as well as a link to java.com to download a security update.
While Chrome does give you ability to run the plug-in each time it is used, this can rapidly become a pain in the rear. The checkbox labeled Always Allow also doesn’t seem to work.
So what to do? Well, you can either painstakingly click the Run this time button or you can run Google Chrome with a command line switch that turns off the plugin checking mechanism.
Being an intrepid sort that likes to live on the edge and dance where angels fear to tread, I chose to run with the checking mechanism turned off. To update the Ubuntu application launcher to make this easier, I edited the following file:
/usr/share/applications/google-chrome.desktop
sudo vi /usr/share/applications/google-chrome.desktop
Look for the first instance of a line starting with Exec and alter it to read as follows:
Exec=/opt/google/chrome/google-chrome --allow-outdated-plugins %U
After saving the file and restarting Google Chrome you will no longer be bothered by the annoying Java plug-in error warning. To verify this is working, you can enter the following on the command line:
ps ux | grep -v grep | grep allow-outdated-plugins
You should get back at least one result.
As a bonus, you can ensure that you are running the most recent version of Java (1.7.0_05 as of this writing) by doing the following on a command line:
java -version javac -version
You should see something like the following:
foreandy@foreandy-iMac:~$ java -version java version "1.7.0_05" Java(TM) SE Runtime Environment (build 1.7.0_05-b05) Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode) foreandy@foreandy-iMac:~$ javac -version javac 1.7.0_05
So here at work we are running SGHE’s Banner Student Information System. Part of the integration with the eFollett online bookstore isn’t working quite the way we want due to a bug that will not be fixed until Banner release 8.5 which we won’t have until sometime after classes start.
Due to the desire to find the books based on a class now, we had to create a system that would allow us to build the correct URLs for the eFollett system in a programmatic fashion.
The way we did it was to include an anchor tag as custom text within the Banner module. The href attribute of the anchor tag contains an inline Javascript function that is used to pull the querystring parameters from the current Banner URL and pass that off to a separate system that will handle the redirection to the appropriate eFollett URL.
Too bad you have to be logged into the Banner account for it to work, since the query string is only available to an authenticated user.
The inspiration for this was the blog post Read URL GET variables with JavaScript by Ashley Ford.
Recently I ran into an issue with several websites and their functionality, or lack thereof, on Mobile Safari in iOS 4.3.3 on the iPad.
Mobile Safari doesn’t give you much in the way of native debug tools. There is a debug console, which will display, at least in theory, any CSS, HTML or Javascript errors.
The only problem is that it won’t actually display all HTML errors. For instance the problem I ran into was an HTML tag mismatch between an opening H2 and a closing H3. Mobile Safari on iOS 5.1 displayed the page as designed, however on iOS 4.3.3 the bad closing tag was omitted which meant that all the children of that H2 had the CSS style “hidden” applied to them due to a class assignment.
You would think that this might trigger an error code in the debug console, however no such error occurred, and using the Safari iOS 4.3.3 – iPad user agent in desktop Safari on Mac OS X did not exhibit the error.
In searching for a tool to assist with debugging this problem natively on the iPad I ran across a great bookmarklet by Mark Perkins, called Snoopy.
This bookmarklet gives you all kinds of nifty information about the page you are looking at, including a view of the generated source. Thanks to this tool I was able to find out exactly what was breaking the display on the iPad.