Archive

Posts Tagged ‘Configuration’

Update to Installing UniVerse on CentOS post

I’ve been asked a few times on how to get the U2 DBTools products, like XAdmin to connect to their VirtualBox machine. I obviously left something out in the article, so I’ve went back and updated the post for how to configure your firewall. You can follow these same steps for UniData as well.

Just to make sure you don’t miss it, I decided I should also duplicate it here…

Configure firewall

If you want to access UniVerse (say using XAdmin from the U2 DBTools package), you will need to modify your iptables configuration.

First, in my case I have the VirtualBox network adapter set to ‘Bridged’. Now, in a shell window update iptables ‘sudo vi /etc/sysconfig/iptables’

In vi, before any LOG or REJECT lines, add ‘-A INPUT -m state –state NEW -m tcp -p tcp –dport 31438 -j ACCEPT’.

Once that is done, you simple run ‘service iptables restart’ to pick up the changes.

The updated iptables file

The updated iptables file

XAdmin once connected

XAdmin once connected

Advertisements

Installing UniVerse on CentOS 6.2

July 8, 2012 1 comment

Previously we looked at installing UniData on a Linux machine. This time around we are going to install UniVerse on a CentOS 6.2. I’ve chosen CentOS as it is essentially a re-branded (de-branded?) version Red Hat Enterprise Linux. RHEL is officially supported by Rocket Software, making CentOS a great free OS for playing around with U2 databases.

As always, I suggest you do this in a Virtual Machine so that you can create as many dedicated test systems as your heart desires (or storage limits). For this I’ve used Oracle’s Virtual Box which is available for free.

Requirements

Okay, so to start, let’s make sure we have everything we need to do this:

  1. Suggested: Dual Core CPU or better (particularly if running as a VM)
  2. Suggested: 2GB RAM or better (particularly if running as a VM)
  3. Virtual Box software
  4. Latest CentOS LiveCD/LiveDVD ISO (as of 2012/06/07, version 6.2)
  5. UniVerse Personal Edition for Linux

Preparing the VM

After you have installed Virtual Box and have it running, we will need to create a new image to run CentOS. Doing this is as simple as clicking the ‘New’ button and follow the prompts.

Create a new Virtual Machine

Most questions can be left as is, except for the operating system. For the operating system, set it to ‘Linux’ with version ‘Red Hat’.

My old laptop has 2GB of RAM, so I’m assigning 1GB to this machine image.

Setting the Virtual Machine's  memory

I stick with dynamic allocation of my disks for most testing as it is easier to move the smaller images around. For more serious work, you might be better served creating a fixed disk size as it generally performs better.

Selecting the disk type

The default 8GB disk is just fine. You can always create and add more disks later.

Now that you have your machine image ready, select the image and click on the settings button. In this screen click on the storage option and select the DVD drive from the IDE Controller. On the right-side there is a small CD/DVD image you can click on then select the option that let’s you choose a CD/DVD image. This will let you select the CentOS ISO you downloaded so we can boot from it.

Virtual Machine settings

While in the settings screen, you should also add a shared folder and click on the read-only and auto-mount checkbox options.

Installing CentOS

CentOS-UniVerse [Running]

If you are not installing this as a virtual machine, you can burn the ISO image to CD/DVD and start the machine with the CD/DVD in the drive (or on modern machines, via USB drive). Only do this is you know what you are doing or are intending to have CentOS as the sole operating system. From here on in, I’ll be assuming you are taking the VM route.

Select the VM image and click on the start button.

CentOS should auto-boot from the CD/DVD image. Once it has loaded and is sitting at the desktop, there is an ‘Install to Hard Drive’ option. Click on this and follow the installation instructions CentOS provides you. Generally speaking, the default options are the ones you want.

Early on in the installation CentOS will issue a ‘Storage Device Warning’. This is for your newly created 8GB disk. In this case you can select ‘Yes, discard any data’. Warning: If you are not doing this in a VM, you must know what you are doing or you risk losing data.

Storage Device Warning

Where it asks you for hostname, you can leave it as the default. I’ve taken to naming them {OS}.{DB} in lowercase; so in this case I’m naming it ‘centos.universe’.

Once the installation is finished, you can restart the VM image. Be sure to remove the CD/DVD image so that it boots from the hard drive. It will ask you a few final questions once it restarts (such as entering a non-root user) before it takes you to the login prompt.

To make our life easier, once we have logged in, we will add ourselves to the list of allowed sudoers. To do this, open a terminal window by selecting Applications -> System Tools -> Terminal. I also added this shortcut to the desktop since I use it so much.

In the terminal, switch to the root user by running ‘su -‘. We can now edit the list of sudoers using visudo. At the end of the file, add ‘{user} ALL=(ALL) ALL’ where {user} is the username you created for yourself earlier.

Now is a good time to shut down and take a back-up of the image so you can clone as many freshly minted VM’s as you want. I also try to do some common tasks such as installing/updating gcc (terminal: ‘sudo yum install gcc’), installing Google Chrome (http://google.com/chrome) and ant (terminal: ‘sudo yum install ant’) first.

Installing UniVerse

Download UniVerse Personal Edition inside your VM image and place it into a temporary directory.

While you are waiting for it to download, you can create the ‘uvsql’ user we will require later. From the ‘System’ menu, select ‘Administration’ -> ‘Users and Groups’. Once you have the program up, click on the ‘Add User’ button, then fill in the username and password fields. Click ok and exit out of the user manager.

Create uvsql user

Open up a terminal window then change to your temporary directory where the UniVerse download is located. The first step will be to extract everything from the compressed file; to do this you can type in ‘unzip UVPE_RHLNXENTINT_11.1.9.zip’. Replace ‘UVPE_RHLNXENTINT_11.1.9.zip’ with whatever the downloaded filename is in your case.

The next step will be to extract the uv.load script to install UniVerse. To complete this step, run this command to extract it from the STARTUP archive: ‘cpio -ivcBdum uv.load < ./STARTUP'

You can now run uv.load as root with the following command: 'sudo ./uv.load'. Select 1 on the first prompt to install UniVerse with 'root' as the default owner. This is okay as we are just building a dev system.

On the next screen select option 4 to change the 'Install Media Path' to whatever the path of the temporary location you extracted UniVerse into. In my case it was '/home/itcmcgrath/temp'. The rest of the options are okay being left set to the defaults. Press [Enter] to continue with the installation process.

UniVerse will now be installed then put you into an administrative program. [Esc] out of this to drop to a UniVerse prompt then type in 'QUIT' to drop back to the command line.

There you have it, a working UniVerse server running in a Virtual Machine. Shutdown your VM and take a copy of the machine image so you have a fresh copy of UniVerse in easy reach.

Installation completed

Update: Configure firewall

If you want to access UniVerse (say using XAdmin from the U2 DBTools package), you will need to modify your iptables configuration.

First, in my case I have the VirtualBox network adapter set to ‘Bridged’. Now, in a shell windows update iptables ‘sudo vi /etc/sysconfig/iptables’

In vi, both any LOG or REJECT lines, add ‘-A INPUT -m state –state NEW -m tcp -p tcp –dport 31438 -j ACCEPT’.

Once that is done, you simple run ‘service iptables restart’ to pick up the changes.

The updated iptables file

The updated iptables file

XAdmin once connected

XAdmin once connected

Disclaimer: This does not create a UniVerse server that will be appropriate to run as a production server.

Installing UniData on Fedora 14

May 30, 2011 5 comments

For some future upcoming posts, I needed to install UniData on a Linux Machine.

Since I’m already going through the effort of freshly installing both Fedora and UniData, I thought I would share required steps so anyone else who wanted to create a similar test system can do so just as easily. It turns out to be quite simple and straight forward, with only minor set up tasks along the way.

Firstly, I suggest you do this in a Virtual Machine so that you can create as many dedicated test systems as your heart desires (or storage limits). For this I’ve used Sun’s Oracle’s Virtual Box which is available for free. To make it easier, I’ve also got instructions for the few extra preparation steps you will need to do the Fedora installation in Virtual Box

Requirements

Okay, so to start, let’s make sure we have everything we need to do this:

  1. Suggested: Dual Core CPU or better (particularly if running as a VM)
  2. Suggested: 1GB RAM or better (particularly if running as a VM)
  3. Virtual Box software
  4. Fedora 14 ISO
  5. UniData Personal Edition for Linux

Preparing the VM

After you have installed Virtual Box and have it running, we will need to create a new image to run Fedora. Doing this is as simple as clicking the ‘New’ button and follow the prompts. Most questions can be left as is, except for the operating system. For the operating system, set it to ‘Linux’ with version ‘Fedora’.

The default 8GB Dynamic disk is just fine. You can always create and add more disks later.

Now that you have your machine image ready, select the image and click on the settings button. In this screen click on the storage option and select the DVD drive from the IDE Controller. On the right-side there is a small CD/DVD image you can click on. This will let you select the Fedora 14 ISO you downloaded so that it will boot from it.

While in the settings screen, you should also add a shared folder and click on the read-only and auto-mount checkbox options.

Installing Fedora

Fedora 14 VM for UniData

Fedora 14 VM for UniData


If you are not installing this as a virtual machine, you can burn the ISO image to CD/DVD and start the machine with the CD/DVD in the drive. Only do this is you know what you are doing or are intending to have the Fedora as the sole operating system.

If you are installing this as a virtual machine, select the VM image and click on the start button.

Fedora should auto-boot from the Fedora image. Once it has loaded and is sitting at the desktop, there is an ‘Install to Hard-Disk option’. Click on this and simply follow the installation instructions Fedora provides

Installing UniData

Before you can install UniData on Fedora 14, you must first install the libgdbm.so.2 library. You can download and install the RPM for libgbdm.so.2 here

Apart from the above missing dependency, it is as simple as following the installation manual provided by Rocket Software.

The only other point of note from the initial installation is that not all the escape characters in udtinstall are processed correctly, so expect to see a few lines like “\tWould you like to continue?”

Now you will need to set up the environment variables you will need. To do this, ensure you are in a shell as root or that you run these commands as root. Change to the /etc/profile.d directory. In here we are going to create a unidata.sh file that will contain all the environment variables UniData requires.

Just type in ‘gedit unidata.sh &’ to bring up a text editor (or just use vi/emacs) to paste the following into:

   UDTHOME=/usr/ud72 ; export UDTHOME
   UDTBIN=$UDTHOME/bin ; export UDTBIN
   PATH=$PATH:$UDTBIN ; export PATH
   LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$UDTBIN ; export LD_LIBRARY_PATH
   UDTERRLOG_LEVEL=2 ; export UDTERRLOG_LEVEL

Restart the machine or run the new script as root and you should be able to run ‘startud’ as root. If UniData boots up correctly, open a non-root shell and type in ‘cd $UDTHOME/demo’ then ‘udt’ and you should successfully jump into ECL.

There you have it, a working UniData server running in a Virtual Machine

Disclaimer: This does not create a UniData server that will be appropriate to run as a production server.

Categories: Database Tags: , , ,

The problem with numbers

October 11, 2010 4 comments

UniData, like other weakly-typed systems, makes some programming tasks easier by not needing the developer to declare and adhere to a data type with variables. The general pros and cons of this have been debated many times across many languages and hence will not discussed here. What will be discussed is specific cases where this can cause you unexpected headaches.

A posting was made on the u2ug forums by Koglan Naicker about some unexpected issues when finding duplicates in a data-set.

In short, he found that when strings contained large numbers, it would sometimes incorrectly evaluate two different strings as equal. For example:

IF '360091600172131297' EQ '360091600172131299' THEN CRT "Equal"

The above code results in “Equal” being displayed on the screen. This is caused by a combination of 2 factors.

The first being that UniData is weakly typed. This means that it does not explicitly distinguish between strings and numbers, but attempts to determine the data type by examining the data. In this case, since the strings are numeric, it automatically treats them as numbers.

The second part of this issue is because now that it is treating those 2 strings as numbers, it needs to handle them in an appropriate data type on the CPU. Since the 2 strings are too large to be treated as an integer, they get converted to a floating-point number. Due to rounding that occurs, this actually results in both of these strings being converted to the same float-point representation! A better method may have been to use something such as Bignum instead of converted to floating-point. There would be a speed trade-off, but surely that would have been better than potentially incorrect programs.

Some people suggest prefixing or appending a non-number character to each string to force them to be treated as a string. Not entirely elegant and can have performance implications. Fortunately, UniData does have proper functions to handle these situations. In the case where you will be comparing strings that may consist of only numeric characters, you should use the SCMP function. This function compares two strings as strings, regardless of the actual data in them. Using this when you need to be certain how the comparison is performed can save you a lot of headaches in the future.

Also of interest is that this issue doesn’t just apply to UniBasic, but can also affect UniQuery!

It should be noted though, this only affects UniQuery when the dictionary item is right-aligned with the format field (eg, 20R in attribute 5).

You can tested this by creating a file and creating 3 records with the @ID of ‘360091600172130474’, ‘360091600172131297’ and ‘360091600172131299’.

Now, select upon the file where the @ID = ‘360091600172131297″ and you can see that 2 records are returned!

Results of selection

Non Unique Select

When explicitly selected a record via a unique key, this isn’t the result a database should return.

So, when dealing with large, potentially numeric fields with UniQuery, you may need 2 dictionary items. A left-aligned one for selecting on and a right-aligned one if you require numerical sorting.

Security is not Obscurity. Even in U2 [Part 1]

December 6, 2009 2 comments

Sure, we may benefit from whatever shelter is derived from running a less widely used/understood system, but relying solely on security through obscurity with your U2 system is, to put it nicely, extremely naive in this day and age. It just doesn’t add up when you pay thousands of dollars for firewalls and other network security paraphernalia and wouldn’t dream of allowing raw user input through in your SQL-based applications.

U2 may have different syntactical spices and a different method of representing data than its mainstream counterparts but the core principles behind secure coding practices still apply:

The list goes on.

So, what specific vulnerabilities should we look out for?

Let us start with the humble EXECUTE/PERFORM statements in UniData and UniVerse. SQL Injection is a widely know subject, but how many U2 developers have considered UniQuery/RetrieVe Injection? Did you know that in some cases, malformed UniQuery in a EXECUTE can drop you to ECL?

As developers in the U2 world, the same lessons learnt in SQL Injection can and should be applied when using *EXECUTE/*PERFORM, etc. Sanitise your input!

Do you have any statements that work like this?

...
EXECUTE 'SELECT MYFILE WITH FIRST.NAME = "':TAINTED.INPUT:'"'
...

In this case, TAINTED.INPUT is either supplied by a user or is comes from an external source. The results from the SELECT statement are now compromised and can contain any data. Take for instance the following input for this contrived example:

" OR WITH CC.NUMBER = "4657000000000000

Essentially, this converts the innocent SELECT statement which, for example, was used to search for customer’s first names to get contact numbers, into one which can be used to find Credit Card numbers (hopefully though, your CC numbers are encrypted in some manner). Even worse, if your program displays error messages that reveal record names when they cannot be read, then an attacker with patience can reveal almost any data they want from your system.

Remember, in UniData you can use the ‘USING’ keyword to specify any FILE to source the dictionaries (UniVerse does not have this, I believe). Aside the all the usual manipulation of results, the USING means that if someone can control the first few lines of a record (temp data dumping file anyone?) then using the SUBR() call, they can even cause programs and subroutines to be called!

Before you EVER use input from a user or an external source, make sure it is validated and sanitised. Expecting a number? Use MATCH and 1N0N. Expecting a name? Make sure it is doesn’t contain double quotes. Don’t want to allow ‘searching’ with your SELECT? For example, I use the following check to ensure the user input doesn’t escape the SELECT string with double quotes or attempt a wildcard search with [ or ].

IF TAINTED.INPUT MATCH "~'['0X~']'" AND NOT(INDEX(PCNAME, '"', 1)) THEN
   ...

Further to this UniQuery/RetrieVe Injection vulnerability, earlier I mentioned that in certain situations you could cause it to crash to ECL.

Are you running UniData in PICK mode? If you are, I suggest you type ‘UDT.OPTIONS’  at ECL right now and continue down until you see whether ’41  U_UDT_SERVER’ is set to ON or OFF. Now, did it say OFF? If so, then read on because you may be vulnerable.

While that option is turned off, certain malformed UniQuery statements can cause you to crash straight to ECL, even if you are in a program called by a program.

Lets see an example. First, compile the following program in Pick Mode.

CRT "Enter the program to select"
INPUT PROG.NAME
CRT "Executing query..."
EXECUTE 'SELECT BP WITH @ID="':PROG.NAME:'"' CAPTURING INFO RETURNING RESULT
CRT "Checking results..."
IF SYSTEM(11) > 0 THEN
   CRT "Program FOUND!"
END ELSE
   CRT "Program doesn't exist"
END
CLEARSELECT
STOP

Now, when you run the program (I called it CRASHTEST), put a record ID that exists in BP. Try again with a record ID that doesn’t exist. Your results should be something like this:

Normal Program Operation

Normal Program Operation

Looks good. Program works as expected. Underneath this simple program though, lies a bug feature in the Pick Parser. To show this, I will use a specifically formed input that will make the programs SELECT malformed in a manner to gain ECL access. This time when you run the program (with UDT.OPTIONS 41 off) type in this input, including quotes:
" @ID="
In this case, the program will crash out before ever returning.

Crashed from EXECUTE

Crashed from EXECUTE

There are 2 ways to deal with this. The first way is to set UDT.OPTIONS 41 to ON. This will result in the EXECUTE returning so we can handle it whatever way we wish.

The other way is to set ON.ABORT. I created a VOC paragraph for this, called EXCEPTION as follows:

PA
DISPLAY This program aborted

Running the same test above now results in:

Aborted program

Aborted program

Personally, I believe the method that returns control to the program (UDT.OPTIONS 41) and handles it accordingly (always check what was set by RETURNING) is the safest since it doesn’t give away that the program has a compromised EXECUTE statement. However, this may not always be a viable option, so make sure you at least have ON.ABORT set.

%d bloggers like this: