Email Address Password
Remember Me

Or Create a (Free) Account.
2004JanFebMarAprMayJunJul Aug Sep Oct Nov Dec
2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Oct Oct
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016

No articles posted for 08/2016; five most recent entries shown.

Sat 12th Mar 2016 @ 07:16 2016: Jaguar XF Boot Wiring Loom

Keeping for reference, as it will probably need doing again in a few years at this rate! By "Bethpage" at http://www.jaginfo.org/archive/index.php/t-5211.html
All credit to Bethpage, I am just copying it here for my own reference. I'm pretty hopeless at this kind of thing and found it quite easy.
..........................................

As we know a known weak point is the loom between the boot and the boot lid, at some point in it's life a wire is going to break. Lucky for me then it was for the number plate lights, others I know has suffered with the wires for the boot lock.
So having gained knowledge from others on various mods, I thought it was time to give a little back.

The loom (part no. C2Z19874) was obtained from the dealer at £75.55. He needed to know vin number and if the reversing camera was fitted. In the picture the camera video lead has beige and grey plugs.
7889

Tools used, screw driver (2) and two different size interior trim clip removers - the small screw driver was used to un clip the number plate holder from the chrome strip and replace the LED
7890

Remove boot lid liner (11 small clips and the lock cover) to gain access
78917892

Remove hard plastic boot lip trim around lock receptacle (3 clips) to enable easy access behind RHS boot liner (2 clips)
7893 Plastic boot trim clip
7894 Boot liner clip

Access is now available to the loom, undo the plugs at the boot lid and inside the boot. If camera fitted the beige plug is attached to the boot lid whilst the grey plug is within the boot. Un-clip the lead from the boot lid, remove the rubber protection boot from the boot lid and the boot and feed the old loom out. Feed the new loom back in, refit the rubber protection boot to the lid and the boot structure, connect up at either end and push fit the loom clip to the boot lid. Test lights, locking and reversing camera (if fitted)
Refit boot and boot lid trim - reversal of removal
NOTE: with loom unplugged, do not close boot lid unless you have keys in your hand and then you will only get in with the emergency blade.
7895 Boot lid plugs
7896 Boot lid clip
7897 Rubber protective boot
7898 Inside boot plugs

Time taken approximately 45 mins to 1 hour depending on how your trim goes back. The boot lip plastic trim has some cable looms behind it which require to be just in the right place for the trim to go back easily and the clips to go fully home.

Post a Comment               

Mon 22nd Feb 2016 @ 16:27 2016: Puppet duplicate declaration

I've made this mistake a couple of times lately. The result is an error: Duplicate declaration: Exec[chown-etc-ssh-keys] is already declared in file usermanager.pp:18, cannot redeclare at usermanager.pp:18

That error is really frustrating, because it's the same line, and the same file!

 exec { 'chown-etc-ssh-keys':
command => "/bin/chown $name /etc/ssh/authorized_keys/$name",
onlyif => "/usr/bin/stat -c %u /etc/ssh/authorized_keys/$name | /bin/grep -w 0",
}


What is really happening is that you're calling the class multiple times, so you get two instances of "chown-etc-ssh-keys" in this case.

So ensure that the name itself is unique, like this:
 exec { 'chown-etc-ssh-keys-${name}':
command => "/bin/chown $name /etc/ssh/authorized_keys/$name",
onlyif => "/usr/bin/stat -c %u /etc/ssh/authorized_keys/$name | /bin/grep -w 0",
}



See http://stackoverflow.com/questions/25858390/puppet-manifest-has-a-file-declaration-that-somehow-duplicates-itself for more.

Post a Comment               

Thu 27th Aug 2015 @ 05:02 2015: Red Hat Satellite 6 Proxy

Updated the proxy that your Red Hat Satellite 6 server uses? Check all of these files have the correct information, then run "katello-service restart" to restart Satellite:


  • /etc/yum.conf
  • /etc/pulp/server/plugins.conf.d/yum_importer.json
  • /etc/pulp/server/plugins.conf.d/puppet_importer.json
  • /etc/pulp/server/plugins.conf.d/iso_importer.json
  • /etc/foreman/plugins/katello.yaml
  • /etc/rhsm/rhsm.conf

Post a Comment               

Wed 29th Apr 2015 @ 03:56 2015: @server-policy in Red Hat RHEL6

So Red Hat recommend (eg, in https://access.redhat.com/sites/default/files/attachments/red_hat_satellite-6.0-core-soe-en-us_0.pdf) to install the @server-policy group by default on a Red Hat Enterprise Linux 6 installation. Looking at this package group, it seems a bit odd, and I couldn't find any explanation on the internet when I searched for it, so here, for anybody else curious about it, is what I found out.


[root@rhel6 ~]# yum groupinfo server-policy
Loaded plugins: package_upload, product-id, security, subscription-manager
Setting up Group Process

Group: Server Policy
Description: Policy packages for the Server variant.
Conditional Packages:
gdm-policy-server


So it contains only one package, and even that is conditional. Looking in comps.xml Stripping out the multi-language items from comps.xml leaves us with this basic definition:

<group>
<id>server-policy</id>
<uservisible>false</uservisible>
<display_order>1024</display_order>
<langonly />
<name>Server Policy</name>
<description>Policy packages for the Server variant.</description>
<packagelist>
<packagereq requires="gdm" type="conditional">gdm-policy-server</packagereq>
</packagelist>
</group>


So - if you have gdm installed, then it will also drag in gdm-policy-server. I can't find any sign of gdm-policy-server on my Satellite server, nor at http://mirror.centos.org/centos-6/6/os/x86_64/Packages/. So maybe @server-policy is just a completely useless package group?!

Post a Comment               

Wed 25th Mar 2015 @ 09:23 2015: Ancient OpenSSL on Solaris

So I was trying to get a custom-built Puppet agent on Solaris 10 to talk to a Red Hat 6 Puppetmaster (all Puppet 3.6.2) and getting the error message:

"Error: Could not request certificate: Unsupported digest algorithm (SHA256)."

https://groups.google.com/forum/#!msg/puppet-dev/_jkdY1Hmq6U/f1IWKZxBHn4J confirms that the problem is that the ancient OpenSSL (0.9.7d) from /usr/sfw doesn't support SHA256.

The answer seems to be to rebuild with a newer OpenSSL, with shared support, and with Ruby using it:
1) OpenSSL
export CFLAGS="-m64 -O2 -fPIC"
export CC=gcc
export AS=gas
export LD=gld


AGENT_DIR=/opt/my-puppet-agent
./Configure solaris64-sparcv9-gcc --prefix=/${AGENT_DIR} --openssldir=${AGENT_DIR}/openssl shared
make
make test
make install
export LDFLAGS="$CFLAGS -R${AGENT_DIR}/lib -L${AGENT_DIR}/lib"
export CFLAGS="$CFLAGS -I${AGENT_DIR}/include"

2) Ruby
For Ruby, the ext/Setup file contains "#openssl" which seems to be to tell it to stub out its own OpenSSL. My pkgconfig is too old for the URL: field, too, so I remove that.

sed s/"^#openssl"/"openssl"/g ext/Setup > /tmp/ext_setup.$$ && mv /tmp/ext_setup.$$ ext/Setup
grep -v "^URL:" template/ruby.pc.in > /tmp/ruby.pc.template && mv /tmp/ruby.pc.template template/ruby.pc.in
./configure --prefix=${AGENT_DIR} --enable-shared --with-opt-dir=${AGENT_DIR} --disable-install-doc --enable-rpath

gmake && gmake install

2 Comments               

Steve's urandom blog
Share on Twitter Share on Facebook Share on LinkedIn Share on Identi.ca Share on StumbleUpon
My Shell Scripting Book:
    Shell Scripting, Expert Recipes for Linux, Bash and more
is available online and from all good booksellers:


DefectiveByDesign.org