Troubleshooting Caption Numbering in Microsoft Word

Problem

You are drafting a document in Microsoft Word.  You embed a number of images in this document, where these images are configured to have text flow around them. You add captions to these images, and these captions are automatically inserted into text boxes that appear underneath these images.  After inserting a number of captions, you observe that the caption numbering is out of sequence (e.g., "3.14," "3.13," "3.12," etc.).  No matter what you do to resolve this problem, such as deleting and then recreating these captions, nothing seems to work.

Discussion

When you embed images in a paragraph, an anchor is inserted into that paragraph.  You can see this anchor if you click on the paragraph symbol (¶).  The problem is (and this continues in Microsoft Word 2010) that each paragraph can anchor only one image.  If a paragraph has multiple images embedded in it, all of these images share the same anchor.  This sharing also applies to the textboxes automatically generated when you add captions to these images: these are effectively linked, and it is this linking that adversely affects the caption numbering.  You can delete, and recreate these captions; move them around; etc, all you want, but nothing here will resolve this problem.  There is however an easy workaround, and it involves using tables.

Resolution

Whenever you need to embed multiple images into a single paragraph, use the following procedure to ensure proper caption numbering:

1. Create a single-cell table.
2. Remove this cells visible boundaries
3. Place the image into this cell.
4. Change the text wrapping of this image to In line with text.
5. Insert a caption for this image.  The caption will appear below the image (still in the cell), and no textbox will be created.
6. Configure the table default cell margins to be "0" on all sides.
7. Configure the paragraph lines (for both the image and its caption - these are on separate lines) as desired.
8. Set the table wrapping to Around.
9. Move the table where desired in the paragraph.

References

• Microsoft Office Support: Troubleshoot captions

Notes

• None

Migrating the Jive SBS Database Step-by-Step

Introduction

This procedure walks you through migration of the Jive SBS 4.5 internal database to a new separate instance of PostgreSQL 8.4.  Use this walkthrough when upgrading from the initial standalone, test Jive SBS instance to a full production instance.  Though this walkthrough focuses on migration of a PostgreSQL database, the method that you will learn here can be applied to any type of Jive SBS database migration.  It will also work for Jive SBS version 4.0.  Performing the migration involves seven steps: 1) Create database dump files, 2) Create databases, 3) Create user, 4) Assign dump file ownership, 5) Import dump files, 6) Update Jive startup file, 7) Restart Jive, and 8) Test.  Only minimal comments and executable statements are presented here.  Note that each step is presented discretely - skip the exits and logouts if continuing from one step to another.  Good Luck!

Procedure

Step 1: Create Database Dump Files

On the Jive SBS machine:

sudo su - root

cd /usr/local/jive/postgres/bin

./pg_dump -U postgres sbs > /pathToYourHomeDirectory/jive_db_sbs.dump

./pg_dump -U postgres sbsanalytics > /pathToYourHomeDirectory/jive_db_sbsanalytics.dump

On the new PostgreSQL machine:

cp /pathToYourHomeDirectory/jive_db_sbs.dump /tmp/jive_db_sbs.dump

cp /pathToYourHomeDirectory/jive_db_sbsanalytics.dump /tmp/jive_db_sbsanalytics.dump

logout

Step 2: Create Databases

On the new PostgreSQL machine:

sudo su - root

su - postgres

createdb -T template0 sbs

createsb -T template0 sbs

exit

logout

Step 3: Create User

On the new PostgreSQL machine:

sudo su - root

su - postgres

psql postgres

CREATE USER sbs WITH PASSWORD 'password';

GRANT ALL PRIVILEGES ON DATABASE sbs TO sbs;

GRANT ALL PRIVILEGES ON DATABASE sbsanalytics TO sbs;

\q

exit

logout

Step 4: Assign Dump File Ownership

On the new PostgreSQL machine:

sudo su - root

chmod 755 /tmp/jive_db_sbs.dump

chown postgres /tmp/jive_db_sbs.dump

chmod 755 /tmp/jive_db_sbsanalytics.dump

chown postgres /tmp/jive_db_sbsanalytics.dump

logout

Step 5: Import Dump Files

On the new PostgreSQL machine:

sudo su - root

su - postgres

psql sbs < /tmp/jive_db_sbs.dump

psql sbsanalytics < /tmp/jive_db_sbsanalytics.dump

exit

logout

Step 6: Update the Jive Startup File

On the Jive SBS machine:

sudo su - root

cd /usr/local/jive/applications/sbs/home

cp ./jive_startup.xml ./jive_startup.xml.ORIGINAL

vi ./jive_startup.xml

Make the following edits:

<serverURL>jdbc:postgresql://[YourPostgresqlDomainName]:5432/sbs</serverURL>

<password>sbsAccountPassword</password>

:x

chmod 600 ./jive_startup.xml

logout

Step 7: Restart the Jive SBS

sudo su - root

service jive-application - restart

Step 8: Test

Open a browser and point it to your Jive SBS instance.

Summary

Congratulations! In this step-by-step walkthrough, you have been shown how to perform a migration of the Jive SBS 4.5 internal backend to a new and separate instance of PostgreSQL 8.4.  The method presented here has been successfully tested on both versions 4.0 and 4.5 of Jive SBS.  The method presented here focuses on PostgreSQL migration but may be applied to any other type of database migration.

Troubleshooting

If you attempt to perform an import of the dump files, but experience a "Permission Denied" error, perform the following checks:

• Verify that the account being used to perform the import (most likely the "postgres" account) has permission to navigate the directory path to the location of the dump files.
• Verify that the account used to perform the import (most likely the "postgres" account) has permission to read the dump files.

If, after performing this walkthrough, you test the Jive SBS instance and experience an HTTP Status 404 error, perform the following checks:

1. Verify that the password stated in the jive_startup.xml file is the same as that used to create the sbs user.
2. Verify the PostgreSQL server URL and port are correct.
3. Verify that the sbs user has been granted ALL PRIVILEGES to both the sbs and sbsanalytics databases.
4. Verify that the PostgreSQL postgresql.conf file has been configured to allow it to listen to connection attempts ("listen_addresses").
5. Verify that the port stated in the PostgreSQL postgresql.conf file is the same as that indicated in the jive_startup.xml file.
6. Verify that the PostgreSQL pg_hba.conf file has been configured to allow connections from the Jive SBS IP address.
7. Check the PostgreSQL log files located here: .../pgsql/data/pg_log/.
8. Check the Jive SBS logs located here: .../jive/var/logs/.

References

• Database: Frequently Asked Questions - How do I switch databases from, say, MySQL to Oracle? Jive SBS 4.0 Documentation
• Database Prerequisites, Jive SBS 4.0 Documentation
• Jive Database Server - Jive SBS 4.0 Documentation
• Problems migrating to new server, Jive Community Support Forums
• Operations Cookbook - Jive SBS 3.0 Administration

Notes

• Jive SBS 4.5 uses PostgreSQL 8.1 as its internal database.
• This walkthrough was performed on headless 64-bit CentOS 5.5 servers.
• This walkthrough was performed using 64-bit Jive SBS 4.5 and 64-bit PostgreSQL.

Installing Openfire and Integrating it with Jive SBS

Introduction

This step-by-step procedure walks you through installation and integration of the Openfire 3.7.0 chat infrastructure server with Jive SBS 4.0. Openfire is an open source application that implements the XMPP server protocol. It supports instant messaging capabilities for Jive SBS. Integrating Openfire with Jive SBS involves three primary steps: 1) configuring the Jive SBS Real-Time Connection; 2) installing Openfire; and 3) configuring Openfire.

Procedure

Step 1: Configuring the Jive SBS Real-Time Connection

Connect to the Jive SBS Admin console, and the go System > Real-Time. The Real-Time Integration page appears.

NOTE: In version 4.5, Real-Time Integration functionality has been packaged as a separate plug-in.  Thus, you won't see the Real-Time Integration page, when going to the Admin console.  To regain this functionality, install the Jive Connects Plugin for Openfire. You will then see the Real-Time tab again.

Click the connection page link. The Real Time – Connection Settings page appears.

Enter the Shared Secret: [enter any word]

Click the Save Shared Secret button. A green message bar will appear. You will then need to restart the Jive SBS instance in order for the new shared secret to take effect.

Logout of the Jive SBS Admin console.

In a terminal on the server hosting the Jive SBS instance, logon as the Jive user:

$ sudo su - jive

Stop the Jive SBS service:

[jive]# ./bin/appstop -v

Start the Jive SBS service:

[jive]# ./bin/appstart -v

Check the Jive SBS service status:

[jive]# service jive-application status

This completes configuration of the Shared Secret key for Openfire integration. You will need this key in order to integrate Openfire and Jive SBS. In the next section, you will install Openfire.

Step 2: Install Openfire

Logon to the target server

Download the RPM for Red Hat Linux and variants from the Openfire website. For this procedure, the downloaded file name is openfire-3.7.0-1.i386.rpm.

Logon to root:

[user]$ sudo su - root

Copy the RPM to /opt or /usr/bin:

[root]# cp /[path to file]/openfire-3.7.0-1.i386.rpm /opt

Unpack the installation file:

[root]# rpm –ivh openfire-3.7.0-1.i386.rpm

Start the service:

[root]# sudo /sbin/service openfire start

Check the service:

[root]# service openfire status

This completes Openfire installation. The next section walks you through Openfire configuration. You’ll need the Shared Secret key in order to complete this section.

Step 3: Configure Openfire

Open a browser, and then connect it to http://[targetservername]:9090. The Welcome to Setup page appears.

Choose English, and then click Continue. The Server Settings page appears.

Accept defaults, and then click Continue. The Database Settings page appears.

Choose the Embedded Database option, and then click Continue. The Profile Settings page appears.

Select the Clearspace Integration option, and then click Continue. The Profile Settings: Clearspace Integration page appears.

Enter the following:

• URI: http://[yourservername]
• Shared Secret null: [the same text entered previously in Jive SBS]

Then click the Test Settings button. A success message should appear. If not, check the settings you entered and try again.

Click Close. You will be returned to the main page.

Click Continue. The Setup Complete page appears.

Click Login to the admin console. The login page appears.

The Server Information page appears. This completes installation and configuration of the Openfire tool.

Step 4: Uninstallation

Stop the running Openfire process

Delete the Openfire scripts in /etc/rc.d/init.d/ and/or /etc/init.d/

Delete the Openfire installation directory

E.g., /usr/local/openfire OR /opt/openfire OR [yourCustomInstallDirectory]

Delete the launch daemon in /Library/LaunchDaemons/org.jivesoftware.openfire.plist

Delete Openfire preferences /Library/PreferencePanes/Openfire.prefpane

Reboot the machine

Step 5: Troubleshooting Openfire Wizard Setup

The Openfire database schema does not appear to be installed.

Once you begin the Openfire configuration wizard, it’s best to complete it right through without navigating backwards to previous pages.  If you should do this, and if you should need to navigate back to the Database Settings page, you may experience a database schema error may be presented on the page, after clicking the Continue button.

To get around this, just open a terminal on the server hosting Openfire, and then restart the Openfire instance.  You can do this by executing one of the following commands:

[root]# /etc/init.d/openfire reload

Then try running the setup wizard again.

Summary

Congratulations!  You have established a chat infrastructure for your environment and integrated it with the Jive SBS collaboration platform.

References

• Ignite Realtime – Openfire
• Jive Connects for Openfire Plugin - Jive SBS 4.5 Documentation
• Configuring Openfire Integration - Jive SBS 4.5 Documentation

Notes

• TBD

Installation and Configuration of PostgreSQL to a Headless CentOS Server Step-By-Step

Introduction

This procedure walks you through step-by-step installation and configuration of 64-bit PostgreSQL server 8.4.8 onto a headless 64-bit CentOS 5.5 server.  The procedure involves four basic steps: 1) install PostgreSQL, 2) initialize the database, 3) start the PostgreSQL service, 4) create a symlink, 5) ensure ownership, and 6) ensure external client access.  You will install the server only; you will not install any GUI interfaces (such as pgAdmin).  All references used in this walkthrough are provided in the References section.  Good luck!

Procedure

Step 1: Install PostgreSQL

This step will install the PostgreSQL package group that comes with 64-bit CentOS.  This group includes the following packages:

• postgresql-libs-8.4.8-1PGDG.rhel5.x86_64.rpm
• postgresql-8.4.8-1PGDG.rhel5.x86_64.rpm
• postgresql-server-8.4.8-1PGDG.rhel5.x86_64.rpm

Open a terminal on the target server.  Login to the root account.

Install the PostgreSQL server package and its dependencies using YUM.  Be sure to disable gpg signature checking, in order to avoid annoying warnings:

[root]# yum install postgresql-server --nogpgcheck

Installation of this package group will create the following subdirectories:

• /var/log/pgsql
• /var/lib/pgsql
• /usr/share/pgsql
• /usr/lib64/pgsql
• /etc/sysconfig/pgsq

Step 2: Initialize the Database

Note that database initialization on RHEL (and thus also CentOS) will be somewhat different than other Linux flavors.

Execute the following command:

[root]# service postgresql initdb –D /var/lib/pgsql/data

Or, you may need to initialize the database using this approach:

[root]# /etc/init.d/postgresql start

Step 3: Start the Service

Execute the following command:

[root]# /etc/rc.d/init.d/postgresql start

Step 4: Create the Symlink

The default location on RHEL (and thus also CentOS) systems is /var/lib/pgsql.  However, applications such as bash will expect the location to be /usr/local/pgsql.  This can be fixed via soft symlink:

[root]# ln –s /var/lib/pgsql   /usr/local/pgsql

Step 5: Ensure Ownership

Check to make sure that the postgres account owns the pgsql directory and subdirectories:

[root]# ls –l /var/lib

If not, you will need to change ownership.  When changing ownership, do so recursively.  Test the account by logging into it and then performing stop and start commands:

[root]# su – postgres 

-bash-3.2$ pg_ctl –stop 

-bash-3.2$ pg_ctrl start

Step 6: Enable External Client Access

Stop the PostgreSQL instance so that you can edit configuration settings files:

[root]# service postgresql stop

Save a copy of the original configuration file:

[root]# cp /var/lib/pgsql/data/postgresql.conf /var/lib/pgsql/data/postgresql.conf.ORIGINAL

Update the PostgreSQL configuration file to enable it to listen in on the server IP address at the default port:

[root]# vi /var/lib/pgsql/data/postgresql.conf

Uncomment the line “listen_addresses” and set it equal to ‘*’.  Uncomment the “port” and leave it set to the default port (5432). Save a copy of the original security access file:

[root]# cp /var/lib/pgsql/data/pg_hba.conf /var/lib/pgsql/data/pg_hba.conf.ORIGINAL

Update the PostgreSQL security access file to enable client access to this PostgreSQL instance from within the subnet

[root]# vi /var/lib/pgsql/data/pg_hba.conf

Identify the mask appropriate to your network.  For example, if it is 255.255.255.0, you would add this line:

host all all 192.168.0.0/24  md5

Additionally, if you want to be able to use a GUI to interact with this postgresql instance over a VPN, you’ll need to identify the IP address that is received by the PostgreSQL instance and add this to the list of hosts allowed to connect.  For example, if your VPN IP address was 69.143.195.130, then to allow only your IP address to be able to connect you would add the following:

host all all 69.143.195.130/32  md5

Startup the postgressql service back up:

[root]# service postgresql start

This completes this PostgreSQL installation procedure.

Summary
In this step-by-step walkthrough, you installed the 64-bit version of PostgreSQL server 8.4.8 onto a headless 64-bit CentOS server.  Congratulations!
References

1. PostgreSQL Home Page: http://www.postgresql.org/.
2. PostgreSQL 8.4.8 Documentation: http://www.postgresql.org/docs/8.4/static/index.html.

Notes

• TBD

How to Secure Your Small-network Firewall Step-by-step

Introduction
 
The following procedure walks you through the process of securing your small network firewall.  Specifically, it walks you through securing an integrated cable gateway/firewall device that functions as your small network's primary access point.  This walkthrough is based upon securing the Linksys WCG200 integrated cable gateway modem access pont.  However, the methods presented here are applicable to all home and small network access points.  This walkthrough assumes that you have correctly configured your gateway for ISP connection and that you are able to access the gateway's administration web page.  It assumes a wired network and does not examine wireless security. It does not address all aspects of home network gateway configuration: only those specific aspects associated with firewall security.  This walkthrough is organized into five steps: 1) disabling remote administration, 2) enabling stateful packet inspection, 3) enabling common packet inspection rules, 4) configuring port filtering, and 5) enabling VPN passthrough.  References pointing to additional details on the topics covered in this walkthrough are provided in the References section.  Good Luck!

Procedure

Step 1: Disable Remote Administration

Remote administration can be hacked using dictionary attack methods.  Best to disable it.  Set Remote Administration to Disable.

The default password on Linksys appliances is often "admin."  Now you know it.  So does everyone else.  Best to change it to something different; something difficult.  Best to create a password that meets the following minimum guidelines:

• Minimum 8 characters
• At least one number
• At least one upper and one lower case numbers
• At least one special character (subject to what your firewall allows)

One last thing: it's bad practice to allow an external device to be able to remotely reconfigure your gateway/firewall.  What happens if a trojan hijacks your machine and discovers your machine can reconfigure your firewall?  That's what UPnP allows.  Disable it.  It's not worth the trouble to use it.

Step 2: Enable Stateful Packet Inspection

To enable your firewall to look inside packets and filter them based upon their contents, you need to enable Stateful Packet Inspection (SPI). Without SPI switched on, your firewall is handicapped.  Go to the security section of the admin console.  For the WCG200, go: Security > Firewall.  Select Enable for Firewall Protection.

Step 3: Enable common Packet Handling Rules

Some common packet handling rules that you should enable include rules for blocking:

• Fragmented packets: used to perform IP fragmentation attacks
• Anonymous Internet requests: used to discover your network topology, including IPs and ports, and to initiate connections to machines on your network - bad news: block these
• Multicast: used to perform DDoS and remote code execution attacks

Go to the appropriate page to enable these rules.  For the WCG200, go: Security > Firewall.  Then enable options as discussed:

Don't disable Cookies, Java Applets, ActiveX, or popups, as they are needed for most browser viewing of websites. Proxy should be blocked.  It's aslso useful to enable Port Scan alerting: this will log such scans for later analysis. Port scanning is performed by attackers to discover open ports.

Step 4: Configuring Port Filtering

There are 65,535 ports.  You only need to use a few of these.  The rest are open doors to trojans and drive-by surveillance efforts.  A number of ports are known entry/exit points for various trojans, viruses and worms.  Lock them up and block them out.

Before blocking them out, do your homework.  Take an inventory of your special needs: some applications (e.g., games) use special ports; distributed applications may employ special ports; if you VPN to special URLs, log the ports you connect to.  Use terminal commands, such as netstat, to monitor ports and build a baseline inventory of those ports that are commonly used.  TCPView is also a good tool for this.  After a few days of monitoring, you'll build a pretty good idea of what to block and what not to block.  You can do this incrementally: block a certain range; see what happens; if nothing, then block another range - in this fashion, you slowly and inexorably lock down the firewall. Don't panic if you block a port range and then discover that something no longer works.  Just unblock the port range.  That will fix the problem.  Here are common ports you need to keep open:

Port Number	Service	Description
3389	RDP	Remote desktop, both TCP/UDP
995	POP3	Incoming POP3
587	SSL	Outgoing SMTP
443	SSL	Encrypted website access
110	POP3	Unencrypted email transfer to email server from your machine
80	WWW	standard WWW access
68	DHCP	Communication with your ISP for modem configuration information
67	DHCP	Communication with your ISP for modem configuration information
53	DNS	DNS queries
25	SMTP	Unencrypted email transfer from email server to your machine
23	SSH	Secure shell connection to machine on private network
22	SSH	Secure shell connection to machine on private network
21	FTP	Ftp command
20	FTP	Ftp data transfer

To set up port filter on the WCG200, go: Access Restrictions > Filter Internet Traffic. The WCG200 provides you the ability to specify 10 port filtering ranges. Your own gateway/firewall may be different. On a spreadsheet, map out the ranges that you want to filter. Then enter them into the screen. The following image shows the results of such mapping for a typical home gateway/firewall.

The port filtering rules have been enabled for all devices (0.2-0.254) on the home network.  Note that one special port in the upper range was kept open.  You may need to do likewise.

Step 5: Enable VPN Passthrough

If you connect to a corporate or other private network over the Internet, you must enable virtual private network (VPN) passthrough.  In 2011, most machines use IPsec.  PPTP is still supported for backwards compatability.  Unless you know you need to use PPTP, disable it.

Summary

Congratulations!  You've completed this walkthrough.  Bet you didn't think you could configure such a technical device as your  small network firewall.  For further information on the topics discussed in this walkthrough, consult the references.

References

• List of TCP and UDP port numbers, Wikipedia
• COMMON PORTS Cheat Sheet, PacketLife Blog, Jeremy Stretch
• Wireless-G Cable Gateway (WCG200), Linksys (Cisco) support
• IP fragmentation attacks, Wikipedia
• Port scanner, Wikipedia
• PORT NUMBERS, Internet Assigned Numbers Authority
• netstat, Wikipedia
• TCPView v3.04, Windows SysInternals
• Firewall Port Security, Chaminade
• Intrusion Detection FAQ: What port numbers do well-known trojan horses use?, SANS
• Remote Desktop Protocol

Notes

• This walkthrough based upon the Wireless-G Cable Gateway, WCG200 ver.2.
• Filtering ports on the WCG200 doesn't stop your machine from using those same ports to launch connections.  It only prevents connections to these ports from being initiated by external sources.
• An excellent tool for active testing of your firewall is available at Gibson Research: https://www.grc.com/x/ne.dll?bh0bkyd2.  Lots of other useful firewall-related information at this site.
• Top 5 Free Antivirus for 2011, PCWorld 2011
• The Best Free Antivirus Software, PCMag, 7/19/2011
• ZoneAlarm Free Firewall 9.2, PCMag, May 24, 2010

SharePoint 2007: Resolving Service Unavailable Error after WSS SP2 Installation

Problem

You have a MOSS 2007 instance loaded to and operational on Windows 2003 Enterprise Server SP2.  You successfully update WSS to SP2.  You then successfully complete the Configuration Wizard. However, at the end of the Configuration Wizard, when it automatically tries to connect to the Central Administration (CA) page, it is unable to and you experience a Service Unavailable message.

Troubleshooting

You then check the Windows System event log and find multiple instances of Error 1059 messages.  This error suggests that the problem may involve application pool identities.  You reset the application pool identity associated with CA.  You then try again to connect to CA, but still experience a Service Unavailable message.

Solution

Reboot the machine.

Notes

• None

Setup Anonymous User in JIRA Step-by-step

Introduction

In this step-by-step walkthrough, you will be shown how to fully implement an anonymous user in JIRA.  Setting up Anonymous User in JIRA involves three discrete steps: 1) configuring the permission scheme, 2) configuring the field configuration scheme, and 3) configuring the default assignee.  Each of these steps is presented here.  Additionally, you'll also perform a fourth step involving test and verification of the implementation.  All references used in this walkthrough are listed below in the References section.  Good luck!

Procedure

Step 1: Configure Permission Scheme

Open JIRA.  From the Administration menu, select your target project.  The main project page appears.

Look for Permission Scheme, and then click Edit.  The Edit Permissions - Default Permission Scheme page appears.

In the Project Permissions table, look for Browse Projects, and then click Add.

For my project, I want anonymous users to be able to create issues and also to browse projects.  Using the CTRL key, select both of these.  Then, to the right, select the Group radio button, and make sure that the Anyone group is selected.

Then click the Update button.  The settings will be saved, and your browser will be navigated back to the Edit Permissions - Default Permission Scheme page.  If you check the Browse Projects and Create Issues project permissions, you'll see that these have been updated to include the Anyone group.

Step 2: Configure Field Configuration Scheme

Go back to the main project page.  Look for Field Configuration Scheme, and then click System Default Field Configuration.  The View Field Configuration page appears.  Note: if you have Secure Administrator Sessions enabled, you will need to login in order to proceed to this page.

Scroll down the table until you see the Reporter row.  Note that it currently indicates Required.  You'll need to change this.

Click the Optional, in the third column over.  The page will refresh.  If you then scroll down to the Reporter row again, you'll see that this link has now changed to Required.  Note: you may need to refresh the page again in order to see this link updated.

Step 3: Configure the Default Assignee

You can configure the default assignee as either a user or as Unassigned.  You'll review both options here.  Let's start with Unassigned.

From the Administration menu, select your target project.  On the left navigation bar, under Global Settings, look for the Global Configuration link.

Click General Configuration.  A page appears listing general configuration settings.

Scroll down until you see the Options table.  Look for the Allow unassigned issues item. 

By default, this is set to OFF.  To enable it, click Edit Configuration, at the bottom of this page.

Make the change, and then click the Update button at the bottom of the page.  If you take a look, the setting will have been changed.

Now, lets review configuring a user as the default assignee.  From the Administration menu, select the target project.  Look for Permission Scheme.  Click Edit.  The Edit Permissions - Default Permission Scheme page appears.  Scroll down the table until you see the Assignable User row.

Click Add.  The Add New Permission page appears.  Select the Single User radio button, at right, and then enter or select the user that you want to be the assigned user.  Also, even though the Assignable User permission is selected by default, at left, be sure to click on it once.  This actually sets it.

Now click the Add button, at bottom.  The browser is navigated back to the Edit Permissions - Default Permission Scheme page.  Scroll down a bit until you see the Assignable User issue permission.  Note that now a specific user is also shown (in this case test1).

That's it.  You're done.  In the next and final step, you will perform a test on this change to verify its implementation.  For this test, the Assigned User option was implemented and will be tested.

Step 4: Verification

Exit out of the browser instance you used to configure JIRA.  Then open a new browser instance and point it to the JIRA main page, but don't login just yet.

In the upper right-hand corner, look for Create Issue.  Click on this.  A small popup will appear, requesting additional information.

Select the project and type of issue, and then click Create.

Enter the information as desired for your test.

When done, click the Create button, at bottom.  The browser will be navigated to a page displaying the new issue.

Congratulations!  This completes this walkthrough.  Happy coding!

References

• Allowing users to create issues anonymously, JIRA 4.4 EAP Documentation
• Defining a Project, JIRA 4.4 EAP Documentation
• Configuring JIRA Options, JIRA 4.4 EAP Documentation
• Managing Project Permissions, JIRA 4.4 EAP Documentation
• Creating a Notification Scheme, JIRA 4.4 EAP Documentation

Notes

• This walkthrough was performed using JIRA 4.3.3 installed in stand-alone configuration on CentOS 5.5 running as a guest OS in VMware Workstation 7.1.4.
• Whether going with Unassigned or setting up a default assignee, you can configure alerts that will be triggered regardless.  Alerts are triggered on state changes.  To learn more about configuring alerts, see the link in the References section, above.

How to install Sun Java 1.6 onto CentOS 5.5

Discussion

In this step-by-step walkthrough, you will install Sun Java JRE 1.6.0_25 onto CentOS 5.5.  CentOS comes available with openJDK, an open source Java version.  Some applications (such as JIRA) may not be fully compatible with this version and require the standard Sun JRE or JDK to function properly. Sun Java is not available via YUM.  Installing Sun Java on CentOS is simple, but there are some wrinkles that, if not properly addressed, will cause some needless troubleshooting.  These steps are not fully discussed by the Sun Java installation instructions.

Procedure

Download the Linux binary (not the rpm.bin version).

Create a new directory:

mkdir /opt/java

Copy the binary into this new directory

Change the permissions of the binary:

chmod 755 /opt/java/jre-6u25-linux-i586.bin

Launch the binary:

/opt/java/jre-6u25-linux-i586.bin

NOTE: you will not experience a license prompt while this is executing - this is a variation from the Sun Java instructions for this.

Verify that the java directory was created:

ls -l /opt/java

You should see this:

jre1.6.0_25

Change java directory permissions to allow all user access:

chmod 755 /opt/java

Create a new global environment variable for Java with system-wide access:

gedit /etc/profile.d/java.sh

or use

vi /etc/profile.d/java.sh
Add the following lines to this file:

export JRE_HOME=/opt/java/jre1.6.0_25
export PATH=$PATH:$JRE_HOME/bin

export JAVA_HOME=/opt/java/jre1.6.0_25
export JAVA_PATH=$JAVA_HOME

export PATH=$PATH:$JAVA_HOME/bin

Save and exit.

Verify that the new file has been created:

ls -l /etc/profile.d

One of the items listed should be the following:

java.sh

Load this new global environment variable:

source /etc/profile.d/java.sh

Verify that the new environment variables are active:

echo $JAVA_HOME

This should return (for this procedure):

/opt/java/jre1.6.0_25

Repeat this process for the other global environment variables you created.

Or check for all Java environment variables:

env or printenv

Configure alternatives:

alternatives --install /usr/bin/java java /opt/java/jre1.6.0_25/bin/java 2

Now select which Java is default:

alternatives --config java

This returns

  Selection    Command
-----------------------------------------------
+ 1           /usr/lib/jvm/jre-1.6.0-openjdk/bin/java
   2           /usr/lib/jvm/jre-1.4.2-gcj/bin/java
   3           /opt/java/jre1.6.0_25/bin/java
Enter to keep the current selection[+], or type selection number:

Select 3, or which ever number is associated with the version just installed.

Verify configuration:

java -version

This will return:

java version "1.6.0_25"
Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
Java HotSpot(TM) Client VM (build 20.0-b11, mixed mode, sharing)

This completes this procedure on Sun Java installation to CentOS 5.5.

References

• HowTo Install Java on CentOS 4 and CentOS 5, CentOS, 10/10/2010.
• CentOS – Install Java Sun JDK, Eureka.
• Installing Sun's Java on CentOS 5.2, Chris Shuld Blog.
• Help with java installation, CentOS Forums - Applications Support, 5/11/2007.
• Setting Global Environment Variables in CentOS, Allied Technique, 4/16/2009.

Notes

• None

Intalling the Default Apache HTTP Server on CentOS Step-by-Step

Introduction

In this step-by-step walkthrough, you will install and configure the default Apache HTTPD server on CentOS 5.5.  This default web server is available for installation and configuration, after including the Server and Server GUI package groups during a CentOS 5.5 installation.  Total time to completion is approximately 15 minutes.  Good luck!

Procedure

On CentOS, an Apache HTTPD server will likely already have been installed.  A simple check can verify this.  Open a terminal, and then enter the following:

httpd -v

This command will print the version and patch level of the installed httpd server. 

To find out more about this command and its arguments, enter: man httpd.

Though the Apache httpd web server is installed, it has not yet been started nor fully configured.  First, let's check to see what the current boot configuration for the httpd service is.  You'll use the chkconfig utility [1, 2].  At the terminal prompt, enter the following:

chkconfig --list httpd

This returns the httpd service status for each of the various runlevels [3].  Note the configuration for runlevels 2, 3, and 5.  This service needs to be started at boot for runlevels 2, 3, and 5.  Therefore, at the prompt, enter the following:

chkconfig --levels 235 httpd on

Runlevel 3 is multi-user text mode and 5 is multi-user graphic mode.  2 I'm not sure about: it's user-defined, but I'm not aware of the definition in this context.  Maybe a reader can assist.  Anway, after running this command, check the status again using the previous command.  You should see something like the following:

Now let's start the web service.  You'll use the service command.  You can use the graphical Services Configuration tool as well [4], but executing a command is much faster.  First, check it's status.  Enter the following command:

service httpd status

This returns that the service is stopped.

Now enter the following command [5]:

service httpd start

This starts the service.

TIP: to learn more about the service command, enter man service at the prompt.

Now to configure the Apache HTTP server service.  This can be done either using commands or using the graphical interface tool.  We'll use the tool here.  On the Gnome panel, go System > Administration > Server Settings > HTTP.

The HTTP tool appears [6].  On this tool, enter the fully qualified domain name.  Select the All available addresses... item listed in the Available Address list.

Click Edit.  The Edit an address... tool appears.  Select the Address option, and then enter the server's IP address.

Click OK.  The tool closes, and you are returned to the HTTP tool, with the revised address now listed.

All other settings can be left as default. Additionally, SSL is not addressed in this walkthrough.  Click OK.  A prompt will appear.

Click Yes.  Another prompt will appear.

Click Yes again.  The configuration directive changes you have made are saved to the Apache HTTP Server configuration file, /etc/httpd/conf/httpd.conf.  Now, restart the HTTP service.  Enter the following:

service httpd restart

This restarts the service, causing your configuration changes to be implemented.

Lastly, launch a web browser and then point it to your server IP:

Congratulations!  This completes this step-by-step walkthrough of installing and configuring the default Apache HTTP server onto CentOS 5.5.  Happy computing!

Troubleshooting

httpd dead but subsys locked

You may see this error after using the Services Configuration tool to restart the HTTP server.

As a check, exit and re-open the Services Configuration tool, and then scroll down and select the httpds service again.  If the status is now httpd (pid 21123) is running, you can ignore the subsystem lock error.

References

1. Runlevel Utilities - Red Hat Linux Deployment Guide - Section 1.4.2
2. chkconfig - Red Hat Linux 5 Deployment Guide - Section 16.5
3. Runlevels - Red Hat Linux 4 Reference Guide - Section 1.4.1
4. Services Configuration Tool - Red Hat Linux 5 Deployment Guide - Section 17.3
5. Starting and Stopping httpd - Red Hat Linux 5 Deployment Guide - Section 23.3
6. Apache HTTP Server Configuration - Red Hat Linux 5 Deployment Guide - Section 23.4

Notes

• Apache HTTP Server, Red Hat Enterprise Linux 5 Documentation, Chapter 21
• How to install Apache Server on CentOS, RedHat, Linux, Antoine Solutions Development
• Starting Apache, Apache HTTP Server Version 2.2, Apache.Org
• VirtualHost Examples, Apache HTTP Server Version 2.2, Apache.org
• Apache HTTP Server Project Welcome page