Skip navigation
All Places > Blackboard Developer Community > Blog > Authors mkauffman
mkauffman

ALL FILES No More

Posted by mkauffman Apr 18, 2017

I'm writing this to announce an upcoming requirement for all Building Blocks (B2s). Currently Blackboard allows the following in a B2's bb-manifest.xml file.

<permission type="java.io.FilePermission" name="&amp;lt;&amp;lt;ALL FILES&amp;gt;&amp;gt;" actions="read,write,delete"/>

The above allows the B2 to write to anywhere on the host file system.

 

Because of the security implications,  Blackboard is asking all B2 developers to remove that permission from bb-manifest.xml by Q4 2017. We'll be communicating this out here on our Community site, via our Partner Newsletter, in an Announcement on Behind the Blackboard, etc.

 

Below is a set of permissions that opens up everything in the Blackboard directories. These are almost as 'bad' as <<ALL FILES>> in that they let you overwrite other Blackboard files and content, for example anything in the vi directory, but are far better than allowing changes to any file in the file system. /- indicates every file and directory beneath the specified folder. Once you get your Building Block functioning with the following, then we recommend reducing the set of permissions to only those directories/files that it needs to access, and only those actions that are necessary.

 

<permission type="java.io.FilePermission" name="${java.home}/-" actions="read"/>

<permission type="java.io.FilePermission" name="BB_HOME/-" actions="read,write,delete"/>

<permission type="java.io.FilePermission" name="BB_HOME/apps/tomcat/temp/-"  actions="read,write,delete" />

<permission type="java.io.FilePermission" name="BB_CONTENT/-" actions="read,write,delete"/>

 

Here is an option for logging only that is less promiscuous, if your B2 doesn't need to write elsewhere in the BB directories.

<permission type="java.io.FilePermission" name="BB_HOME/logs/-" actions="read,write,delete"/>

 

Following is a link to sample code that uses logback to write to blackboard/logs/custom and blackboard/logs/plugins/<vendor_id>-<handle>/

 

blackboard/logs/plugins/<vendor_id>-<handle> is the directory that B2s should be writing to from here on out. It's the only B2-specific directory that makes the B2 specific logs available to the Kibana log visualizer in SaaS.  GitHub - mark-b-kauffman/bbdn-bblogbackb2: Demo the use of Logback to create log files.

 

Please plan to address this soon so that your Building Block will be able to be installed in Q4 2017 and later.

mkauffman

Upgrade Your DVM

Posted by mkauffman Dec 28, 2016

Scott Hurrey mentioned this the other day during our Technical Office hours... You can upgrade a 3000.x DVM using the same installer package that you use for a self-hosted system. This blog post will show you how easy that is, after a brief plug for our office hours. If you've not attended, office hours a great way to get answers to your questions and to network with other developers. The schedule and link to join are on the upper right of this page.

 

Prequel: Before doing following, you may need to upgrade the DVMs Java version. See the required technologies for self-hosted environments for the release you are installing on the help.blackboard.com pages. Post Q4 2018/3500  you will also need to upgrade Postgres to 9.6. It's beyond the scope of this document to explain how to upgrade Postgres from 9.4 or 9.5 to 9.6. It's a standard Ubuntu install. Google on +upgrade +postgresql +9.5 to +9.6 +ubuntu +16.04 and that will get you close the right pages.

 

Here's what you do to upgrade your DVM.You will do all of your work as the vagrant user. Do not use root or bbuser. (Note: See addendum following these instructions for Q4 2018 and later for the resolution to the Access Denied dialog on the login page.)

  1. Stop Learn
  2. Download the installer for the version you want to upgrade to from Behind the Blackboard. Note this only works for Q2 2016 and later.
    1. For this example, I upgraded my DVM from 3000.1.1 to 3000.1.3 (Q2 2016 CU1 to Q2 2016 CU3)
  3. As the vagrant user, create the recommended installation directories.
    1. mkdir /usr/local/bbinstaller
    2. mkdir /usr/local/bbinstaller/3000_1_3/
  4. Create an installer.properties file. I've placed the full text for one that works for a DVM below.
    1. Place the installer.properties file in the /usr/local/bbinstaller directory.
  5. Make a copy of the license file. You MUST do this because the install will mess everything up if the installer.properties is pointing to a license file inside the blackboard directory that is being upgraded.
    1. cp /usr/local/blackboard/config/license/blackboard-license.xml /usr/local/blackboard-license-copy.xml
    2. chown vagrant /usr/local/blackboard-license-copy.xml
  6. Move the downloaded .zip installer file to the /usr/local/bbinstaller/3000_1_3/ directory
    1. The trick here is that on the DVM the /vagrant directory is the same directory as the host directory where you ran the vagrant up and vagrant ssh command. You place the .zip installer file into that directory, then on the DVM guest you can move it from into the installation directory.
  7. cd /usr/local/bbinstaller/3000_1_3/
  8. unzip learn-installer-3000.1.3-rel.70+214db31.zip
  9. Run the upgrade
    1. ./installer.sh -c /usr/local/bbinstaller/installer.properties
  10. Run PushConfig, which will also start the server.
      1. cd /usr/local/blackboard/tools/admin
      2. ./PushConfigUpdates.sh

 

That's it! Below are the contents of the installer.properties file that works for upgrading a DVM:

 

# DVM installer.properties for upgrade. First attempt was from Q2 2016 CU1 to CU3.

# Kauffman 2016.12.28

bbconfig.basedir=/usr/local/blackboard

bbconfig.java.home=/usr/lib/jvm/java-8-oracle

 

# cp /usr/local/blackboard/config/license/blackboard-license.xml /usr/local/blackboard-license-copy.xml

# chown bbuser /usr/local/blackboard-license-copy.xml

bbconfig.file.license=/usr/local/blackboard-license-copy.xml

 

## these properties should not be modified manually ##

antargs.default.vi.db.name=BBLEARN

antargs.default.vi.stats.db.name=BBLEARN_stats

 

# just like the Windows upgrade, the Linux upgrade fails if you don't have these 3 dummy antarg lines

antargs.default.users.administrator.password=passworddoesnotmatter

antargs.default.users.integration.password=passworddoesnotmatter

antargs.default.users.rootadmin.password=passworddoesnotmatter

 

############## properties listed here can be modified ###############

antargs.default.vi.db.password=postgres

antargs.default.vi.stats.db.password=postgres

antargs.default.vi.report.user.password=password

 

Addendum for Q4 2018 and Later:

With Q4 2018 and later the bb-cookie-disclosure makes it impossible to login. so you have to upgrade through the PushConfigUpdates as described above. Check that the system is up and running and that you do get stuck because of the cookie disclosure issue - you see Access Denied on the login page. Then use the ServiceController.sh to stop Learn,

cd /usr/local/blackboard/cache/plugins

rm -rf bb-cookie-disclosure

cd /usr/local/blackboard/content/vi/BBLEARN/plugins

rm -rf bb-cookie-disclosure

and finally use PushConfigUpdates.sh to start Learn. Ignore the errors in the stdout-stderr log you get because of the missing bb-cookie-disclosure plugin. At this point, I was able to login and use my upgraded DVM.

 

NOTE: If you use vagrant destroy to stop the system you will need to repeat this process. Using vagrant halt allows you to stop and start the DVM without doing so. However, with halt you may run into other odd behavior like the DVM hangs for a very long time without stopping, etc. I've had to fiddle with the machine when using halt, but have been able to keep using the same box. It's your choice on whether to use destroy and just know that you need to remove the bb-cookie-disclosure every time, our use halt and fiddle.

mkauffman

Simple SaaS Logging Tips

Posted by mkauffman Sep 20, 2016

A recent conversation with a Partner was the impetus for this blog post. We have documentation here on logging here Preparing Your Building Blocks For Learn SaaS. But the Partner asked "In the old days, I would use System.out.println and see the data in stderr-stdout.  Can you suggest how to do something as simple as what I want?" If you long for the good old days there's good news! You can still write log entries to the tomcat stdout-stderr file and then view them in Kibana.

 

Here is an example. I've added the following to a B2's home controller:   System.out.println("springmvcb2 - Is this visible in Kibana? I didn't intentionally log it in the correct format."); Here is a video showing how to find that log entry in Kibana: http://screencast.com/t/tu1m9RO6vNKZ

(For some reason the link to the screencast above is given an odd name by Jive. Ignore that, and click the link.)

 

The code for the B2 is here GitHub - mark-b-kauffman/springmvcb2: demo spring controller to handle requests and copy handler. You will also find in this code example how to set up log4j as discussed here Preparing Your Building Blocks For Learn SaaS. In the code from github you see this line: logger.error("There was NOT an error. This is a test message."); This creates an entry that you can find using Kibana as shown here: http://screencast.com/t/bkFrnVw1PBVG

 

Another good recording on using Kibana to look at logs:   https://www.screencast.com/t/tdw9JCXlzeYF

 

Happy Coding!

 

MBK