Author Archives: alesk

Installing ArcServe 17.5 agent on Oracle Linux 7.4

We’re slowly migrating our DB servers to Oracle Linux 7 and at the same time we’ll upgrade ArcServe 16/16.5 backup software to version 17.5. Unfortunately, the information that we found on the web regarding support for Oracle Linux 7.x is not consistent with the readme document that comes with the media.
Here is what official ArcServe Backup compatibility matrix is saying about OEL7 support:


And below, you’ll see what we got during agent installation. We believe that this inconsistency is due to the poor installation script maintenance (apparently updated in 2015). The installation of the agent 17.5 (+ mandatory patch 802!) on Oracle Linux 7.4 was a breeze .

$ lsb_release -d
Description:    Oracle Linux Server release 7.4

$ su - root
# mkdir /media/arcserve
# mount -t iso9660 /dev/cdrom /media/arcserve
# cd /media/arcserve/Arcserve_Backup/DataMoverandAgent/Linux

./install

This distribution of Linux is not certified by Arcserve Backup. If you run it, you may experience problems.
(y) to continue, (q) to quit :

<< a lot of license gibberish that you'll likely skip >>

Please enter your choice:[Y|N] (default: N)Y
Do you want to view the installation notes? (y/n):(default: y) n
Do you want to view the installation notes? (y/n):(default: y) n

Preparing for the installation, please wait...|

The following products are available to install:


#####################################################################
#       Arcserve Installation Options
#####################################################################
#  1. Arcserve Backup for Linux Data Mover                               (ABdatmov)
#  2. Arcserve Backup for Linux Client Agent                             (ABagntux)
#  3. Arcserve Backup for Linux Agent for Oracle                         (ABora)
#  4. Arcserve Backup for Linux Enterprise Option for SAP R/3 for Oracle (ABsap)
#  5. Arcserve Backup for Linux Enterprise Option for SAP HANA           (ABhana)
#
#  0. Quit
#####################################################################

Note: Client Agent will be installed automatically if Data Mover is selected.
Please enter your selection separated by "," For example: 1,2. Press Enter to select the default components (E.g. Data Mover, Client Agent)...

Your choices are:2

Please specify the installation path of Client Agent for Linux                   (default: /opt/Arcserve):

The following program will be installed:

  . Install Client Agent for Linux                     (ABagntux)      ==> [ /opt/Arcserve/ABuagent ]

Are you sure? (y)es/(n)o/(q)uit: y

All Arcserve Backup agents can be configured for automatic startup
and shutdown as part of your operating system startup and shutdown.
Do you want to enable automatic startup and shutdown of all backup agents? [y|n]:(default: y) y

Checking available space in /opt/Arcserve                     ==> [ OK ]


Installation log file is                           ==> [ /tmp/ARCserveInstall092117-1219.log ]

    Common Agent Module                      (ABcmagt)       ==> [ INSTALL SUCCESSFUL ]
    Client Agent for Linux                   (ABagntux)      ==> [ INSTALL SUCCESSFUL ]

###########################################################################

    Installation log file is                      ==> [ /tmp/ARCserveInstall092117-1219.log ]
###########################################################################


Do you want to view the readme? [y|n]:(default: y) y


<**snip** AND HERE IS THE LIST OF SUPPORTED OS's, OEL 7 is not mentioned! **snip**>

3.2  Supported Operating Systems for the Client Agent for Linux

You can install the Arcserve Backup Client Agent for Linux
on the following operating systems:

 *   Community ENTerprise Operating System 5.x, including SMP
     through 6.3 (x86, AMD64, Intel EM64T)

 *   Oracle Enterprise Linux Server 5.5 including SMP through
     6.3 (x86, AMD64, Intel EM64T)

 *   SUSE Linux Enterprise Server 9.x including SMP through 11
     SP2 (x86, AMD64, Intel EM64T)

 *   Novell Open Enterprise Server 2 10.x (x86, AMD64, Intel
     EM64T)

 *   Novell Open Enterprise Server 11, SP1 (AMD64, Intel EM64T)

 *   Turbolinux 11.x (x86, AMD64, Intel EM64T)

 *   Miracle Linux 4.0 (x86, AMD64, Intel EM64T)

 *   Red Flag Data Center Server 5.0 (x86, AMD64, Intel EM64T)

 *   Asianux 3.x (x86, AMD64, Intel EM64T)

 *   Debian 5.x through 6.06 (x86, AMD64, Intel EM64T)

 *   Ubuntu Server 10.04 LTS through 12.04 (x86, AMD64, Intel
     EM64T)

 *   Red Hat Enterprise Linux Server 4.x including SMP through
     6.3 (x86, AMD64, Intel EM64T)

 *   Red Hat Enterprise Linux 7 (AMD64, Intel EM64T)

 <**snip**  ........................................................... **snip**>

That’s it. We can start or stop the agent with the usual commands:

Start and stop the agent:
 
sudo  /etc/init.d/bab_agent stop
sudo /etc/init.d/bab_agent start

or simply:

caagent stop
caagent start

You should also download and apply patch P00000802.zip before putting agent in production:

Download patch P00000802.zip from ArcServe support.

# cd /home/alesk/Downloads/ArcServe-Patch/
# unzip P00000802.zip
# caagent stop
Shutting down Arcserve Backup Universal Agent process...Down.

-- backup original file
# cp -p /opt/Arcserve/ABuagent/uagentd /opt/Arcserve/ABuagent/uagentd.BkpP00000802

# cp uagentd /opt/Arcserve/ABuagent
# caagent start

If you have firewall enabled, then you’ll have to add port 6051 to the exception list:

sudo firewall-cmd --permanent --zone=public --add-port=6051/udp
sudo firewall-cmd --permanent --zone=public --add-port=6051/tcp
sudo firewall-cmd --reload

Agent configuration:

Configuration:

$ sudo nano /opt/Arcserve/ABcmagt/agent.cfg

[0]
#[LinuxAgent]
NAME      LinuxAgent
VERSION   17.5
HOME      /opt/Arcserve/ABuagent
#ENV      CA_ENV_DEBUG_LEVEL=4
ENV       AB_OS_TYPE=ORACLEAMERICA_X86_64
ENV       UAGENT_HOME=/opt/Arcserve/ABuagent
#ENV       LD_ASSUME_KERNEL=2.4.18
ENV       LD_LIBRARY_PATH=/opt/Arcserve/ABcmagt:$LD_LIBRARY_PATH:/SharedComponents/lib:/opt/Arcserve/ABuagent/lib
ENV       SHLIB_PATH=/opt/Arcserve/ABcmagt:$SHLIB_PATH:/SharedComponents/lib:/opt/Arcserve/ABuagent/lib
ENV       LIBPATH=/opt/Arcserve/ABcmagt:$LIBPATH:/SharedComponents/lib:/opt/Arcserve/ABuagent/lib
ENV       CAPKIHOME=/opt/Arcserve/ABcmagt/ETPKI
BROWSER   cabr
AGENT     uagentd
MERGE     umrgd
VERIFY    umrgd
NOPASSWORD                     <<< ADDED...enable single user mode, this is needed for ACL's
CAUSER A:alesk N:root          <<< ADDED...Access Control List (A=allow access, N=Deny Access)

[36]
#[ABcmagt]
#NAME     ABcmagt
#HOME     /opt/Arcserve/ABcmagt
#TCP_PORT  6051
#UDP_PORT  6051
#UDP_BCAST_PORT  41524
#DOS_MAXITEMS    1000
#DOS_DEFAULTTIMEOUT   30
NO_HOSTS_EQUIV=1               <<< ADDED...disable UNIX/Linux host equiv. authentication

$ sudo caagent stop
$ sudo caagent start

Please, can someone deliver some cloud “stuff” to Oracle Support?

Can you tell me what is wrong with this screen capture that I took on MOS and is part of my Service Request?

Right now, I’m waiting SR analyst to download and install Oracle software, so that he can run query provided by us. I hope that they have at least a decent bandwidth, if they’re not able to use provisioned virtual machines in the first place. And that is the same company touting their cloud offerings. LOL.

20th anniversary

When I started to work for a current employer in 1995 the company run a tiny Oracle 6 production database on IBM mainframe (OS/390). Nothing serious or big. The majority of data processing at that time was still done in Cobol and TPL. Development with Oracle*Case of the new state Business registry however started on LAN, with Oracle 7 on Netware 4. Yes. Life. Was. Exciting. Recovery from a server crash was almost a daily routine. But for a starter like me, it was definitely fun and exciting working environment.
In the mid 90’s company was using a myriad of OS’s (OS/390, Netware 3 and 4, OS/2, DOS, Windows 3.1, Windows 3.11, Windows NT 3.5, SCO Unix, IRIX….but not Windows 95!). We used two network protocols, primary one was IPX/SPX and secondary was TCP/IP (Oracle Listener was listening on IPX/SPX adapter). It was a ZOO.
After Microsoft released Windows NT 4 at the end of 1996, the decision was made to consolidate OS environment on NT 4 at every level, from laptops, desktops to the servers. With one exception. Two main file servers were left to run on Netware.
Why not Unix? Due to the lack of skilled workforce with strong Unix skills on the market it was somehow logical choice to pick a mainstream OS player.
So, on March 1997 we put our first non-mainframe production Oracle database in use. It was IBM PC Server 320 with two Pentium 133Mhz processors, a whooping 128MB of RAM and four 2GB Fast Wide SCSI disks. We run NT 4 and Oracle 7.3. Backups were done with ArcServe and HP Surestore DAT tape library. This first PC based host was (predictably) named ORANT.

At that time we were considered as weirdos (perhaps we still are?), because no one run Oracle production on Windows. Local Oracle representatives used us as a reference whenever someone asked them if anyone is using Oracle on NT or how stable Oracle is on NT. Honestly, from 1997-1999, it was not as stable as we wished to be (regular monthly reboots were needed), but it was certainly a giant leap forward compared to Oracle on Netware. The real stability came with Windows 2000/2003. Twenty years later our production still runs on Windows Servers, but this is gonna to change soon. Not because of the lack of stability (modern Windows Servers are rock solid, and we can prove it;) but because of clear Tux technology dominance and advantages in the Cloud/OSS era.

Anyway, I took a couple of screenshots from my VirtualBox guest, running Windows NT 4 (SP1) and Oracle 7.3.4:

For the record: installation of the Windows NT 4 took ~10 minutes. Installation of Oracle 7.3.4 with Replication option took another ~10 minutes (including building a database). It took 1.3GB of disk space for both OS, RDBMS and sample database. For comparison, Oracle 12c R2 ISO file with all the components is 9.7 GB.

Using ssh tunneling to gain access to remote VirtualBox guest attached to NAT

I’m building virtual machines on a weekly basis, sometimes daily. Most often I create various Linux distros as guests on VirtualBox hosts. VirtualBox hosts are either Windows or Linux computers. Majority of guests are built for test purposes only, so they often live in a “cage” behind a VirtualBox NAT. Guests with NIC attached to NAT have access to the LAN and Internet, but the opposite is not possible out of the box. So my typical NIC configuration for VirtualBox guest looks like this:

Fortunately, VirtualBox allows to configure port forwarding for NAT attached NIC’s. For every Linux guest I setup port forwarding for ssh (22), so that I can use MobaXterm (on Windows7/10) to connect to the Linux guest from the host itself. That’s how it looks:

That’s fine, as long as you have access to the host where your VBox guest is running, you can use MobaXterm to connect to the virtualbox guest. Seating at Windows 7 workstation we simply open MobaXterm and type:

Sometimes, I build virtual machines that I want to access from other machines as well and I don’t like to weaken security by attaching guest NIC’s to a Bridged adapter. Again, let’s call wonderful ssh to the rescue.

Situation: VirtualBox host is a Windows 2008 R2 Server (I’ll refer to this host as VBOXHOST). On this host we’re hosting Linux guest (OL7ORA12R2) with the latest Oracle 12.2 installation. Guest is behind a NAT, but with a port forwarding setup for ssh as shown above (picture 3). I would like to have access to this guest from remote workstation running Windows 7. All machines (physical Windows 7 & 2008R2, plus virtual Linux 7) are firewalled with ssh ports (22) left opened. On Windows 2008R2 is already running OpenSSH (Cygwin).

All that we need to do to get sqlplus access to remote Oracle 12.2 running in Linux guest from Windows 7 workstation is this:

On Windows 7 we start MobaXTerm terminal and run (note that by default Mobaxterm uses implicitly -X for ssh):
$ ssh -L 12201:localhost:12201 alesk@vboxhost -t ssh -L 12201:localhost:1521 alesk@localhost -p 2222

First, we're asked for password to connect to vbohost (Windows 2008 R2), then we're asked for password to login to virtual machine guest (Linux).

Note, that we must left the MobaXterm window open for a duration of SQL*Plus session that follows...

Now, we can connect from Windows 7 Workstation to the remote Oracle DB,  first open cmd and type:
cmd> sqlplus /nolog
cmd> connect c##alesk@'localhost:12201/ORA122'

What happens is illustrated on this picture:

  1. On Windows 7 we launched MobaXterm and run ssh command:
  2. $ ssh -L 12201:localhost:12201 alesk@vboxhost -t ssh -L 12201:localhost:1521 alesk@localhost -p 2222
    
    ssh -L 12201:localhost:12201 alesk@vboxhost  ........... tunnel #1 forwarding port 12201 (Windows 7) to port VBOXHOST (port 12201), in both cases on localhost.
    ssh -L 12201:localhost:1521 alesk@localhost -p 2222 .... tunnel #2 forwarding port 12201 (VBOXHOST) to port 1521 inside VirtualBox Guest, using port 2222 redirection done by VirtualBox itself. 
    
  3. On Windows 7 we opened sqlplus, connecting to localhost:12201. SSH redirected traffic to VBOXHOST:12201 (hop 1), followed by second redirection (hop 2) to Listener running inside VirtualBox.

What if we would like to run some GUI application on Linux guest? We can use X session forwarding, allowing us to see the GUI on our Windows 7 workstation. Like this:

We must open two MobaXterm terminals on Windows 7 workstation.

In the first MobaXterm terminal we type:

$ ssh -L 2222:localhost:2222 alesk@vboxhost

In the second MobaXterm terminal we type:

$ ssh alesk_guest@localhost -p 2222
alesk_guest@mint18 ~$ xclock &

….and xclock will popup on Windows 7 workstation but actually running on Linux guest. Note that alesk_guest is a Linux user on LinuxMint 18 guest and that guest is configured in the same way as before, behind a NAT and with ssh port forwarding (2222) at VirtualBox level. This option is handy to lauch Oracle gui configuration tools, like dbca, netca etc.

Unicode and Oracle SQLcl…on Windows — solved

I was struggling with sqlcl on Windows 7 to properly display our umlauts (we’re using Windows 7 desktops with NLS_LANG=SLOVENIAN_SLOVENIA.EE8MSWIN1250 setup in the registry — note: sqlcl is not reading this variable).
When I read Jeff Smith blog post “Unicode and Oracle SQLcl…on Windows” I though that my problem was solved. Someone reading an article without reading the comments would assume that sqlcl works out of the box on Windows with proper UTF-8 support, which does not. Partly due to the omission of proper parameter in supplied sql.bat file, but mostly because of the state of cmd.exe (powershell.exe) in versions of Windows 7 and below, Windows 10 is much better.

In this demo we’re using Windows 7 EE (Windows 10 EE), Oracle 12c R1 and sqlcl-4.2.0.16.308.0750-no-jre.zip.

First, we created test table called UMLAUT in SQL*Developer and inserted our umlauts:

sqlcl-utf8-01

Then we run a query from this table with sqlcl. Note an extra line between the rows returned from the query….

sqlcl-utf8-02

ok, how about writing some umlauts on the command line….

sqlcl-utf8-03

Well, we can write umlauts but console won’t show us what we wrote (note a presence of squares)…nevertheless the result of the query is correct.

What we can do? Well, for a start we need to patch the officially supplied sql.bat script.

Open sql.bat and replace line

SET STD_ARGS=-Djava.awt.headless=true -Xss10M

with

SET STD_ARGS=-Djava.awt.headless=true -Xss10M -Dfile.encoding=UTF-8

But don’t celebrate yet…what we achieved is this….

sqlcl-utf8-04

We still have an extra line between the rows, which is annoying, but at least we can see what we wrote in the WHERE condition. Plus an extra square :-)…if you’re “lucky” Windows 7 user.
However, above patch is enough on Windows 10, where, both writing of umlauts and properly displaying the records (without extra blank line) works as expected….

sqlcl-utf8-05

The only “workaround” that we found for Windows 7 clients is to simply forget about official console applications (cmd.exe and powershell.exe) as a “host” for sqlcl and use some alternative. We found out that ConEMU works great…(patch in the sql.bat is of course still mandatory until sqlcl guys do this for you).

sqlcl-utf8-06

And what about the suggestion that we can tweak the registry and permanently change the console application (cmd.exe) code page to UTF? Don’t do this, because you’ll disable some non-java applications, including SQL*Plus…look what happens with sqlplus.exe….

sqlcl-utf8-07