Author Archive

Ubuntu 12.04.4, TvHeadend and Realtek RTL2832U USB tuner

This week I setup an old Dell Optiplex 755 tower with Ubuntu 12.04.4, TvHeadEnd and Realtek RTL2832U USB tuner to perform some DVB-T recordings. The installation I performed of TvHeadEnd is the exact same one I documented some months back when I used the same USB tuner on a Raspberry Pi. You can read about it here.

The installation was flawless and simple as you’d expect. The system has been running a few days now and capturing what I want. It also allows me to point VLC client on other machines at the system to network stream any of the DVB-T channels the tuner can tune against (also shown in the previous post linked above).

Thinking of buying another tuner to be honest, so I can record from 2 different channels that don’t share the same stream/multiplex id.

LiPo battery failure

Dug out my LiPo 3S batteries on the weekend with the intent of charging them up for some use in the Traxxas E-Revo brushless. Unfortunately it appeared they had gone bad. As I revived one of them I found one of the cells had gone and the other I never bothered tinkering with.

I’ve since wrote them off as failed and purchased a new set. Now waiting for the new ones to arrive so I can have battery connectors soldered onto them.

Simpana 10 – advanced client properties – firewall – outgoing routes UI change

Noticed that the Simpana 10 Advanced client properties – firewall – outgoing routes user interface changed a little between SP5a and SP6. It may have happened on SP5b, but I couldn’t test at the time, but saw the difference certainly between our jump from SP5a to SP6.

Check out the pictures below to see what I mean. Looks like they relabelled some items.

Advanced Client Properties - Outgoing routes - SP5a

Advanced Client Properties – Outgoing routes – SP5a

Advanced Client Properties - Outgoing routes - SP6

Advanced Client Properties – Outgoing routes – SP6

More Simpana 10 content

I was asked to write up a MySQL related post on how to backup MySQL with the Simpana 10 MySQL iDA and how to configure a test machine.

I am currently working on this and should be posting it in the next month, so keep an eye out. It will follow along the same lines as the PostgreSQL one I posted earlier. As seen here.

Additional backyard work

Went on to complete the backyard work, and sort out another area down the side of the house. I just need to circle back and fix up some drainage which I will do in the next few weeks, as I can’t make a mess of the backyard until after my sons birthday party. So will get stuck into fixing that in the next 2-3 weeks. I put some posts in on the side of the house so we can use it to block the dog down the side when we have events on in the backyard. It also keeps out from running down that side of the house when it’s wet and destroying it.

A few more pictures below;

backyard_29-Mar-2014-pic01

backyard_29-Mar-2014-pic02

Simpana 10 – PostgreSQL 8.4 backup on CentOS Linux 5.10 x64 – example

I am going to assume that this is a test deployment and as such will expect that you have installed your CentOS 5.10 x64 Linux the way you want it, and I will follow on from that point on what I needed to perform to get the distribution release of PostgreSQL to work with Simpana 10 PostgreSQL iDA to perform a backup. Of course some assumed knowledge present.

  1. Install the postgresql packages onto your  CentOS client.
    $ sudo yum install postgresql84 postgresql-server postgresql-devel
  2. Startup postgresql server for the first time, you need to run initdb switch instead of start for the first time only.
  3. $ sudo service postgresql initdb
  4. We should also enable the service to run at boot moving forward
    $ sudo chkconfig postgresql on
  5. Before we change the authentication method below, we need to set a password that we know for the postgres user in the postgresql database. To perform this we need to change to the postgres user and connect to postgresql database and update the password for the user to something we know.
    $ sudo su -
    # su – postgres
    $ psql
  6. Now at the postgres prompt update the password for the postgres user, unless you want to make your own. Won’t discuss how, just going to show how to set postgresql user password. Be sure to remember what you set the password too, it will be required later on.
    postgres=# ALTER USER postgres WITH PASSWORD ‘password’;
    ALTER ROLE
    postgres=#\q
  7. Postgresql packages distributed with CentOS don’t use md5 password authentication, it defaults to peer/ident based authentication. In this example we will flip this to md5 based authentication, and we will touch on a peer/ident based authentication example in a later post. Perform the changes below to enable md5 authentication.
    $ cd /var/lib/pgsql/data
    $ sudo vi pg_hba.conf
    Find the line at the bottom of the file that looks like the one below;
    local     all     all                ident
    You need to change this to have md5 on the end, i.e. replace ident to be md5 instead. Save the changes.
  8. Now restart postgresql for the changes to take effect. (required)
    $ sudo service postgresql stop
    $ sudo service postgresql start
  9. Now you can test that this has worked by execution as root the command below, and when prompted for the postgres user password authenticate using the password set in step 6.
    # psql -U postgres
    If it worked, you will get the famous postgres=# prompt, in which you can enter \q [enter] to quit it.
  10. Next up we now need to enable archive logs. We need to edit the postgres.conf file which on CentOS rpm based install is /var/lib/pgsql/data and the lines we need to add in the Archiving section is below;
    archive_mode = on
    archive_command = ‘cp %p /var/postgresql/archive/%f’
    Save those additions and move on below.
  11. Make sure to create the folders/destination used in the archive_command above and ensure postgres user can write to it etc.
  12. Now restart postgresql for the changes to take effect. (required)
    $ sudo service postgresql stop
    $ sudo service postgresql start
  13. Install the Simpana PostgreSQL iDA.
  14. Once installed refresh the Simpana Console and attempt to create your PostgreSQL instance. See the dialog below for the values I used in this configuration. Of course the username is the postgres user and password we configured in step 6. Note the archive log directory is the one we used in the archive_command string at step 10 too.
    simpana_10-centos-5.10_x64-postgresql_instance_creation
  15. If everything goes to plan you should have your instance created and now you can do configuration against the DumpBaseBackupSet subclient and/or FSBasedBackupSet subclient. For the difference between what each does, I recommend you review the documentation. As each backupset has its own unique capabilities. See the bottom of the Backup documentation page for explanations.
  16. Assign a Storage Policy to each subclient and run a backup of each to confirm it works.

CommVault Documentation references:

Simpana 10 – Linux client prepost command execution failure

Came across an interesting condition today, which took me a bit of testing to identify why the job would go into a pending state. This one relates to Simpana 10 on a Linux client where you have a File System iDA with a PrePost command being executed. In my test below the script is doing nothing special, it’s merely to have something to execute to show the behavior. I’ve provided it below purely for reference.

[root@jldb1 bin]# cat pre-scan.sh
#!/bin/sh
# test
#

echo $1 $2 $3 $4 $5 $6 $7 $8 $9 >> /root/pre-scan.log
exit 0

Job goes pending and produced the following errors and output below;

JPR (Job Pending Record)
Error Code: [7:75]
Description: Unable to run [/usr/local/bin/pre-scan.sh] on client.
Source: jwcs, Process: startPrePostCmd

simpana_10-linux-prepost-command-execution-failure

[JobManager.log – commserve]

3024  d88   03/27 18:16:26 21  Scheduler  Set pending cause [Unable to run [/usr/local/bin/pre-scan.sh] on the client.                 ]::Client [jwcs] Application [startPrePostCmd] Message Id [117440587] RCID [0] ReservationId [0].  Level [0] flags [0] id [0] overwrite [0] append [0] CustId[0].
3024  118c  03/27 18:16:26 21  Scheduler  Phase [Failed] message received from jwcs.lab.heimic.net] Module [startPrePostCmd] Token [21:3:1] restartPhase [0]
3024  118c  03/27 18:16:26 21  JobSvr Obj Phase [3-Pre Scan] for Backup Job Failed. Backup will continue with phase [Pre Scan].

[startPrePostCmd.log - commserve]

4940  e4c   03/27 20:21:46 ### Init() - Initializing job control [token=21:3:7,cn=jwcs], serverName [jwcs.lab.heimic.net], ControlFlag [1], Job Id [21]
4940  e4c   03/27 20:21:47 ### Cvcl::init() - CVCL: Running in FIPS Mode
4940  e4c   03/27 20:21:48 ### CVJobCtrlLog::registerProcess(): successfully created file [C:\Program Files\CommVault\Simpana\Base\JobControl\4.940]
4940  e4c   03/27 20:21:48 ### ::main() - jobId 21 - restoreTaskId = 0
4940  e4c   03/27 20:21:48 ### ::main() - jobId 21 - adminTaskId = 0
4940  e4c   03/27 20:21:48 ### ::getBackupCmdAndMachine() - jobId 21 - before construct application id
4940  e4c   03/27 20:21:49 ### ::getBackupCmdAndMachine() - appTypeId = 29
4940  e4c   03/27 20:21:49 ### ::getBackupCmdAndMachine() - jobId 21 - symbolic AppId = 2:20
4940  e4c   03/27 20:21:49 ### ::getBackupCmdAndMachine() - jobId 21 - prePostId = 1
4940  e4c   03/27 20:21:49 ### ::getBackupCmdAndMachine() - jobId 21 - preifind cmd = /usr/local/bin/pre-scan.sh
4940  e4c   03/27 20:21:49 ### ::main() - jobId 21 - commandPath = /usr/local/bin/pre-scan.sh
4940  e4c   03/27 20:21:49 21  ::main() - jobId 21 - before execute cmd
4940  e4c   03/27 20:21:49 21  ::main() - jobId 21 - Use Local System Acct.
4940  e4c   03/27 20:21:49 21  ::main() - jobId 21 - remoteexename = [/usr/local/bin/pre-scan.sh]
4940  e4c   03/27 20:21:49 21  ::main() - jobId 21 - args = [ -bkplevel 1 -attempt 7 -job 21]
4940  e4c   03/27 20:21:49 21  executePrePostCmd() -  Attempting to execute remote command on client [jldb1]..
4940  e4c   03/27 20:21:49 21  executePrePostCmd() - jobId 21 - Received error text from server cvsession [Unknown Error]
4940  e4c   03/27 20:21:49 21  executePrePostCmd() - jobId 21 - Error [0] returned from executeRemoteCommand /usr/local/bin/pre-scan.sh
4940  e4c   03/27 20:21:49 21  EvEvent::setMsgEventArguments() - MsgId[0x0700004b], Arg[1] = [117440623]
4940  e4c   03/27 20:21:49 21  EvEvent::setMsgEventArguments() - MsgId[0x0700004b], Arg[2] = [/usr/local/bin/pre-scan.sh]
4940  e4c   03/27 20:21:49 21  EvEvent::setMsgEventArguments() - MsgId[0x0700004b], Arg[3] = []
4940  e4c   03/27 20:21:49 21  EvEvent::setMsgEventArguments() - [MsgId[0x0700004b][]: [3] Args Pushed, [1] Args expected.
4940  e4c   03/27 20:21:49 21  ::exitHere() - jobId 21 - Exiting due to failure.
4940  e4c   03/27 20:21:49 21  BKP CALLED COMPLETE (PHASE Status::FAIL), 21. Token [21:3:7]
4940  e4c   03/27 20:21:53 21  ::exitHere() - jobId 21 - startPrePostCmd Terminating Event.
4940  238c  03/27 20:21:53 21  CVJobCtrlLog::unregisterProcess(): successfully removed file [C:\Program Files\CommVault\Simpana\Base\JobControl\4.940]

[cvd.log – client]

30846 427e0940 03/27 20:21:50 ### [CVipcD] Requests from non-CS with hostname [jwcs.lab.heimic.net] and clientname [jwcs] to execute in user entered path are not allowed

I worked out this problem is caused by lack of value in regkey sCSGUID as found in the location below;

/etc/CommVaultRegistry/Galaxy/Instance001/CommServe/.properties

Sample below;

[root@jldb1 ]# cat /etc/CommVaultRegistry/Galaxy/Instance001/CommServe/.properties | more
bCSConnectivityAvailable 1
sCSCLIENTNAME jwcs
sCSGUID
sCSHOSTNAME jwcs.lab.heimic.net
sCSHOSTNAMEinCSDB jwcs.lab.heimic.net

sCSGUID should be populated and its lack of value causes this condition with pre-scan script execution.

Fix:

Easiest method to recreate this regkey value is to do a local uninstall of the simpana services on the client. Revoke the client certificate in Simpana Console via Control Panel – Certificate Administration for the client in question. Followed by a reinstall.

Observation:

Subclients that have no scripts being executed as part of the backup will run fine if this regkey value is missing. You will never see a problem until you add a script. In addition, clients that have a simpana firewall configuration will be broken and subclients without scripts will break too. As the regkey value is used for simpana firewall configuration exchange I believe based on my testing.

Hope you enjoy my post… drop me a comment if you like the content and/or it helps you.

Simpana 10 – Specifying the Media Parameters for RMAN Command Line Operations – example

An recent addition to Simpana 10 Oracle iDA over Simpana 9 was the ability to specify Media Parameters for RMAN Command Line Operations, which wasn’t possible in Simpana 9.

Below is an example on its use, and the documentation link for review is here.

The client in this example is “jwora1″ running Windows 2008 R2 x64 and an Oracle 11gR2 64bit release. Simpana 10 with a SP4 is installed on client and Commserve – “jwcs”.

RMAN Script:

run {
allocate channel ch1 type 'sbt_tape' PARMS="BLKSIZE=262144,ENV=(CVOraSbtParams=C:\p.txt,CvClientName=jwora1,CvInstanceName=Instance001)" trace 2;
backup current controlfile;
}

Contents of p.txt file below;

[sp]
SP_Main-jwma1

[mediaagent]
jwma1

Below is a look at the GUI configuration for the Oracle instance “orcl” on client “jwora1″ which shows that third party command line backups should use Storage Policy (SP) – “SP_Main-jwcs”. However as you will not by the running of the job using the Media Parameters it will use a different SP and MediaAgent, as defined by the p.txt file I passed.

rman-cvorasbtparams-example-01

subclient not configured with any SP

rman-cvorasbtparams-example-02

orcl properties showing command line backup should use SP – SP_Main-jwcs by default.

rman-cvorasbtparams-example-03

orcl properties showing log backups would use SP – SP_Main_jwcs by default

rman-cvorasbtparams-example-04

sample execution of my rman backup script – current control file backup

rman-cvorasbtparams-example-05

Commserve Job Controller showing the running job. Note which MediaAgent is used and SP.

If you find my posts of value, please send me some feedback. Especially if you find this post and it helps you in your travels.

UPDATE: And to follow on from the example above, the following is also possible too. If you don’t pass the CvClientName and CvInstanceName on the channel allocation, you can pull those too from the parameters file. Sample below of alternative backup script syntax and parameters file contents. All documented on the documentation link provided top of post.

RMAN Script:

run {
allocate channel ch1 type 'sbt_tape' PARMS="BLKSIZE=262144,ENV=(CVOraSbtParams=C:\p2.txt)" trace 2;
backup current controlfile;
}

Contents of p2.txt file:

[sp]
SP_Main-jwma1
[mediaagent]
jwma1
[CvClientName]
jwora1
[CvInstanceName]
Instance001

The parameter file can have spaces between the definitions like in the top example, which I prefer, as it makes the file easier to read. Where as the p2.txt file has no extra spaces, which also works but makes it harder to read personally.

Enjoy.

Debian Sources List Generator

I remember finding the website sometime ago where you can generate your Debian Sources file. Turns out I needed to do just that today and I did a Google and found the link.

Such a great idea and it works so nicely. Check it out here.

Kudos to the author.

CommVault Simpana 10 Service Pack 6 now GA

Well it looks like CommVault Simpana 10 Service Pack 6 now GA. Appears to have come out over the weekend. Guess some of us will be upgrading as time permits and change requests get approved.

Don’t forget to read the release notes…

simpana_10_sp6_ga