Then the lightbulb turned on in my head! Why not just create the tablespaces in the Oracle Instance shell myself prior to running the installer and pointing it at the Oracle Instance. We are using Oracle 10G R2 RAC with 11G R1 clusterware on ASM storage. OMF (Oracle Managed Files) are enabled:

SQL> show parameter create_file
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_create_file_dest                  string      +ASM_DBARCH_DATA

So after you execute Blackboard’s required grant step in SQLPlus as oracle:

@$ORACLE_HOME/rdbms/admin/rstrconn.sql;
GRANT create session, create table TO CONNECT;
commit;

…

Then execute this SQL to create the “base” set of Oracle Tablespaces for Blackboard:

CREATE SMALLFILE TABLESPACE "BB_BB60_STATS_DATA" LOGGING;
CREATE SMALLFILE TABLESPACE "BB_BB60_STATS_INDX" LOGGING;
CREATE SMALLFILE TABLESPACE "BBADMIN_DATA" LOGGING;
CREATE SMALLFILE TABLESPACE "BBADMIN_INDX" LOGGING;
CREATE SMALLFILE TABLESPACE "BB_BB60_DATA" LOGGING;
CREATE SMALLFILE TABLESPACE "BB_BB60_INDX" LOGGING; 

note that these SQLs do not cover the CMS tablespaces needed if you’re running the Blackboard (Xythos) CMS.

Here’s the SQL if you’re running the Blackboard (Xythos) CMS:

CREATE SMALLFILE TABLESPACE "CMS_DATA" LOGGING;
CREATE SMALLFILE TABLESPACE "CMS_INDX" LOGGING;
CREATE SMALLFILE TABLESPACE "CMS_FILES_USERS_DATA" LOGGING;
CREATE SMALLFILE TABLESPACE "CMS_FILES_USERS_INDX" LOGGING;
CREATE SMALLFILE TABLESPACE "CMS_FILES_COURSES_DATA" LOGGING;
CREATE SMALLFILE TABLESPACE "CMS_FILES_COURSES_INDX" LOGGING;
CREATE SMALLFILE TABLESPACE "CMS_FILES_ORGS_DATA" LOGGING;
CREATE SMALLFILE TABLESPACE "CMS_FILES_ORGS_INDX" LOGGING;
CREATE SMALLFILE TABLESPACE "CMS_FILES_INST_DATA" LOGGING;
CREATE SMALLFILE TABLESPACE "CMS_FILES_INST_INDX" LOGGING;
CREATE SMALLFILE TABLESPACE "CMS_FILES_LIBRARY_DATA" LOGGING;
CREATE SMALLFILE TABLESPACE "CMS_FILES_LIBRARY_INDX" LOGGING;

Note that this may not be an inclusive list for all installs, but for our work here with Blackboard 7.* through 9.0 SP1 HF2, this has been sufficient. If your installer still errors out after you’ve pre-created the tablespaces, you should investigate the log file that the installer creates and find the name of the tablespace that the installer is failing on. Then , using SQL like what’s above, create whatever tablespace you need.

I found out about all of this when we migrated from OCFS2-backed 10G R2 RAC without OMF (Oracle Managed Files) to ASM-backed 10G R2 with OMF on 11G R1 clusterware, but the solution is actually very simple if you look in the bb-installer.log that the installer creates when you run the jar like /usr/local/jdk/bin/java -jar bb-as-linux-9.0.505.15.jar. When I ran the installer with a /fakepath for the database install path, I saw the failing CREATE TABLESPACE statements referencing the /fakepath. I didn’t want BB to try to name files for the tablespaces, that’s why I’m running Oracle Managed Files. Once I pre-created the tablespaces, everything ran great and the install completed successfully. Detailed solution with example SQL after the break!

I have seen a lot of solutions come across the BBADMIN-L list out of ASU involving complicated solutions where one installs Blackboard 6,7,8 or 9 on non-ASM storage and uses RMAN to migrate the database. Another workaround involved creating a non-clustered database in a RAC environment on local storage and then moving that to the RAC clustered Oracle DB and ASM storage. Both of these solutions time consuming, fraught with places to make mistakes and hose the entire process, and generally a royal pain in the ass. I have a feeling Blackboard already knows this trick and if we’re lucky they’ll eventually publish their version of this article, if they have one.

I hope this helps all my fellow BBAdmins out just a bit. If you’ve got questions or this process blows up on you, please leave me a comment and we can try to figure it out! I have tested this on Oracle 10G R2, both RAC and non-RAC and with Blackboard 7.3.230.0, 8.0.375.0 and 9.0 SP1 HF2, all of which worked AOK.

• Basic knowledge of DNS, how to add/change/delete A/CNAME/RREF records in a generic point and click environment like Windows DNS or a DNS appliance
• Knowledge of DHCP, leases, static DHCP, adding/change/delete leases
• Basic DOS/*nix command line navigation (cd, type, less/more, etc.)
• OS installation, install all drivers, patch system
• Basic virtual machine knowledge, installing OSs inside VMs, cloning VMs, re-IP & re-SID clones, etc.
• Disk drive imaging like ghost
• Network connection troubleshooting knowledge, finding whether problem is local to PC, segment, etc.
• IP subnetting
• Basic Office suite use
• Printer Drivers (enhanced vs os-built in)
• Identifying unknown hardware by reading device IDs, using www.pcidatabase.com or search engine
• Web Browser issues/compatability

That’s it for now — but I’m about to get in the truck for the seven hour drive back to Cincinnati from St. Louis. I may edit this post an add to it when I return, or not. Good luck Aryc!

DISCLAIMER: I still hate windows.

I spent a decent portion of today hunting around for a way to script or otherwise automate (at the command line) uploading a file to one of $wageslavery’s external vendors. After diddling with curl -T only to find that it only works if the destination file doesn’t exist, I finally bit the bullet and installed Cygwin. Cygwin provides a win32 version of expect, the command line automation tool and cadaver, the command line WebDAV utility, basically smbclient for WebDAV. Working example code after the break!

The script is applicable to any platform really, but what’s below on *nix platforms may or may not require the “\n” at the end of the send statements. expect sends “\r” at the end of the line by itself, and I suspect the Cygwin *nix utils running on Windows instead of *nix is probably the cause.

A practical, santized, example including dealing with a self-signed certificate:
spawn /usr/bin/cadaver https://upload.externalvendor.com/myuploads
expect "Do you wish to accept the certificate"
send "y\n"
expect "Username:"
send "starbuck\n"
expect "Password:"
send "0mgBACON\n"
expect "dav:"
send "lcd /path/to/data/files\n"
expect "dav:"
send "rm datafile.csv\n"
expect "dav:"
send "put datafile.csv\n"
expect "dav:"
send "quit\n"

Hopefully this helps some other poor soul stuck dealing with WebDAV uploads instead of proper sftp!

Update 2009-02-24: I added the word “script” a few times to help the Google search results. Maybe I’ll be #1 on “cadaver expect script”!

The Security Center and You

On the test system (Coke) there is a new homepage module that everyone will see when they log in, it is called the security center. Please log in to coke (link only works on campus!) and see things for yourself. You’ll need an account on coke to do this, and you’ll login with your 6+2 and current LDAP/OneStop/etc. password. The Security Center was something I wrote to provide feedback about password related issues such as expiration and grace logins. If the user’s password is expires, but they still have grace logins remaining on their account, they will be able to login to Blackboard but it will consume a grace login and decrement the user’s grace logins available by one. By default, all UC accounts provide six grace logins, and therefor users have six logins before they are locked out and must change their password. I am investigating a way to display grace login and password expiration date in SysOp, but it’s not there yet.

Things to look for in SysOp

Examine Unique Ids Source when you lookup the user’s data. There is a known issue with accounts coming from “B – Grandfathered Beecher accounts”, those accounts do not exist in the LDAP tree that Blackboard authenticates against, and the caller should use their standard 6+2 login name with blackboard instead. This issue should be very rare. When Blackboard attempts to authenticate these users against LDAP, they will be treated in the same way as visitor and other non-LDAP accounts, meaning Blackboard will fall back to their RDBMS (database) password. If the user wishes to continue using the account, inform them they must login with the same password as they did before the conversion to LDAP since their account is being handled as a non-LDAP account.

Sysop showing my LDAP-authenticated account: if the password is expired, there will be a message showing it’s expired

Sysop showing showing a non-LDAP account

Here are a few scenarios that could occur when a user calls with password issues, beyond the standard bad password errors you are accustomed to.

First Scenario

User is unable to log in and receives message a message that their password is expired. The user’s password has expired and they have no grace logins remaining. The user must visit the UCit Password Self Service portal and reset their password, or contact the UC Help Desk for further assistance.

Second Scenario

User’s password is expired, but they were able login by consuming a grace login. Immediately advise the user to visit the UCit Password Self Service before they run out of grace logins. Nota bene: logging in to Password Self Service with an expired password requires at least one available grace login! If the user has just used their last grace login by logging in to Blackboard, and the Security Center displays a value of zero (0) for remaining grace logins, the user must contact the UCit Help Desk to reset their account.

Third scenario

User’s password will expired in less than the warning period (160 days in this case, but it is set to 7 days on the production system, this is for illustration only.) Advise the user to visit the UCit Password Self Service before their password expires.

Fourth Scenario

All is well, user’s password will expire within the configured seven-day warning period. I guess it’s not really a scenario at all.

Password Resets for accounts

Can be done through the UCit Password Self Service portal, or by having the user contact the UCit Help Desk.

Security Center and non-LDAP accounts

Security Center displays a message that the user’s password will not expire. Eventually this module will be hidden for non-LDAP authenticated user accounts. Of course, that “eventually” may be before December 22nd, but not at the time of the writing of this document.

Password Resets for non-LDAP accounts

I am currently doing the engineering before coding my own password reset utility for Blackboard to accommodate the fact that the built-in password reset functionality is not available when bb-config.properties is configured for LDAP authentication. This is very frustrating and I may give Blackboard a call to see if they can tell me how to force it on even with LDAP turned on. If this functionality is not restored, password resets for non-LDAP users will to be handled by the FTRC Blackboard Support Team via phone.

In Conclusion

If you run into issues not covered by this post, please feel free to come find me and ask. Once we solve the issue, we might even add it here. Consider this an experiment in work blogging. I’m looking forward to your comments on this post.