WDTV and CIFS Share issues

June 23rd, 2012 by Russell No comments »

Couldn’t get the WDTV to login to my Windows 7 file share; kept complaining about not being able to access it. Finally resolved it by changing the following parameters in the registry to tell Windows to utilize enough memory to be a fileserver:

Set the following registry key to ’1′:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache

and set the following registry key to ’3′:

Postfix and discarding DSN responses

November 30th, 2011 by Russell No comments »

Had an interesting issue where a remote mail server was responding in its EHLO that it supported DSN, but would not send successful DSN reports as requested. In order to work around the issue I just configured Postfix to ignore the remote mail server’s DSN support:

/etc/postfix/dsn_override: dsn

postmap /etc/postfix/dsn_override

smtp_discard_ehlo_keyword_address_maps = hash:/etc/postfix/dsn_override

Successful “ignoring” should look like this in the maillog:

Nov 30 18:33:33 bigbertha postfix/smtp[22632]: discarding EHLO keywords: DSN

KVM and removing virbr0

February 26th, 2011 by Russell No comments »

Took a lot of headaches and playing around with the network interface scripts:

# virsh net-destroy default
# virsh net-undefine default
# service libvirtd restart
# ifconfig

I was then presented with another issue for bridged networking. For some reason my aliased interfaces (eth0:0, 0:1 etc) would not stop setting their own gateway. This was a problem. In case anyone else runs into this issue, once you have created a bridged interface for your guest OS’s to use, if you have aliased interfaces as well they *must* be bridged off of the bridged interface too. In other words, instead of eth0:0, eth0:1, you will need br0:0 and br0:1.

Postfix, Cyrus SASL and [email protected] login

November 11th, 2010 by Russell No comments »

This took me a bit of Googling to figure out. In order to get Postfix and Cyrus saslauthd to work nicely together using “[email protected]” username format, in /etc/sysconfig/saslauthd add the following flag at the bottom:

# Additional flags to pass to saslauthd on the command line. See saslauthd(8)
# for the list of accepted flags.

Man page for this flag:

-r Combine the realm with the login (with an â@â sign in between). e.g. login:
“foo” realm: “bar” will get passed as login: “[email protected]”. Note that the realm
will still be passed, which may lead to unexpected behavior.

Microsoft Security Essentials – Auto Update Without Windows Update: How to

November 11th, 2010 by Russell No comments »

Here’s a quick method I devised on how to get Microsoft Security Essentials (free: http://www.microsoft.com/security_essentials/) to automatically update without needing to use Windows Update. Many individuals (like me!) like to read what updates MS is wanting to put on your computer before allowing them to do so. The only problem is, Security Essentials wants to always update through Windows Update, so if you have Windows Update set to notify you before downloading, you are having to accept the Security Essentials update every single day. That quickly becomes annoying. Here’s a way around it:
* Download hstart from here: http://www.ntwind.com/software/utilities/hstart.html
This is software that allows you to feed it console commands that it will run silently in the background for you.

* Extract either hstart.exe or hstart64.exe (depending on what version of Windows you are running) and extract it somewhere out of the way, such as C:\Windows

* Add a scheduled task that runs every 3 hours. I have found 3 hours keeps it updated enough that Windows Update won’t bother you about it.

In Task Scheduler:

Program / Script to start: C:\Windows\hstart64.exe (or hstart.exe depending on which one you extracted)
Add Arguments: /NOCONSOLE “%ProgramFiles%\Microsoft Security Essentials\MpCmdRun.exe -SignatureUpdate”

Save the scheduled task, and you are done! Security Essentials will now silently update itself every 3 hours in the background, and you will never have to rely on Windows Update for these updates again!

Note: The location of MpCmdRun.exe has changed in MSE 2.0. The new location is: C:\Program Files\Microsoft Security Client\Antimalware\MpCmdRun.exe


September 18th, 2010 by Russell No comments »

Welcome to my tech notepad! Here’s a dancing bear: