sudo nano /etc/X11/xorg.conf

In the text editor – find the section of the file labeled Section “Device”.  The ending of this section is simply EndSection.  Add the following line before the EndSection statement:

Option    "HWCursor" "false"

Simply restart X either by restarting XBMC or the machine completely.  The cursor should now stay gone for good!

Relevant system specific information:

OS: Ubuntu Desktop 11.04
HDMI Device: XFX ATI 5770

sudo alsamixer

Ensure no devices are muted (indicated by “MM”).

sudo alsactl store 0

This step saves the running alsa configuration

sudo aplay -l

This command will list the installed alsa devices.  Choose the device which you want to output the HDMI audio from – paying attention to the card number and device number.

card 1: Generic [HD-Audio Generic], device 3: HDMI 0 [HDMI 0]

The above information is used to configure a custom audio device within XBMC.  Within the XBMC system configuration settings, change the output device and output passthrough device to custom with the following name:

plughw:1,3  (Note that yours may differ – it is based on the output of the aplay command.

After saving, restarting the machine, and re-launching XBMC, I was now receiving audio over HDMI – though sounds for the system menus no longer functioned (an issue I’ve since ignored).  However, when I played audio, it did not seem as though I was receiving the center channel audio.  I was able to fix this by an odd combination of configuration settings.  While playing a video I set the audio to analog – changed the volume from -60db to 0db, and switched audio back to HDMI.

enable
config t
username USER password PASSWORDHERE privilege 0
write mem

Here’s a good article which covers Cisco Privileges.

enable
config t
snmp-server host Inside 192.168.1.1
snmp-server community SNMPCOMMUNITY
snmp-server enable traps snmp authentication linkup linkdown coldstart

That’s it!  Thanks for reading.

I run a local DNS server on my network – and had made the decision to move away from Mediacom’s DNS servers as my forwarders after testing the speed of theirs in relation to the alternatives.  I am in NO WAY directing my traffic toward the Mediacom DNS servers.  This left me quite confused when I received a Mediacom re-direction page this week after typing a URL incorrectly.  I hopped onto DSLReports and got the scoop.  I found Mediacom has initiated a campaign to increase advertising revenue by automatically redirecting clients to their ad-based redirection site.  The big problem I have with this is – they are completing this by means of deep packet inspection vs. re-directing through their internal DNS servers.  This means it takes precendence over my valid DNS response from an alternative DNS server.

DSLReports stated that opt-out is possible – though it’s also been reported to magically re-enable on occasion.  Follow this link for the opt-out option.

After 20 minutes on hold with Mediacom support, as is usual, customer support gave the same script about the ‘opt-out page’ and the directions to follow.  He stated there is no way for them to verify (as the support offices) who has opted-out, and additionally informed me that it was tracked by the customer’s modem MAC address.

Unfortunately, for us Mediacom subscribers, we are at the mercy of Mediacom to ensure  the opt-out is working correctly.  This post’s purpose is little more than to rant about my own experience – but I hope that it can at least bring some additional attention to these obnoxious, and shady actions by Mediacom in recent months.

logging enable
logging timestamp
logging trap notifications
logging asdm notifications
logging facility 23
logging device-id HOSTNAME
logging host inside SYSLOG SERVER HOSTNAME OR IP
logging debug-trace
logging permit-hostdown

Here’s the syslog section from Cisco’s site if you need more information.

Download WinAgents TFTP Server Manager and run through the installation process. This will setup a tftp server on that Windows machine that you will use to direct the configuration to.  Once installed, connect to the local server.

Once configuration is complete and you are connected to your machine – find the IP of the Windows workstation (we’ll need this in a moment).

Now, connect to the Cisco device.  Login and also enter enable mode:

enable

Once in enable mode, use the copy configuration using the following command:

copy startup-config tftp

You will be prompted for the server address. Type in the Windows workstation IP address here.
You will also be prompted for the name of which to save.  I usually save this as the date and time of the configuration and save it in a folder for the device’s configuration backups – so do whatever method works for you.

Press ENTER and the transfer will begin.  You should notice statistics on transfer are shown.

It’s that simple.  I’ll use this post as a reference to some more in-depth Cisco blogs in the future – but wanted to state it in one place vs. repeating it in each post.  Thanks for reading.

Of course for this to work I had to have pfSense’s DHCP server enabled.  Having this setup will now allow the bootable machines to be assigned a DHCP lease then look for the TFTP server at the address specified (192.168.2.200 in my situation) and to look for pxelinux.0 to boot from.  The next portion of this setup is a slightly modified version of the article found here https://help.ubuntu.com/community/PXEInstallServer , modified in the sense that I left out any DHCP server steps due to the fact that I’m handling the direction through pfSense.

Setting up your PXE server on Ubuntu:

sudo apt-get install inetutils-inetd tftpd-hpa

sudo nano /etc/default/tftpd-hpa

Make sure this file looks like this:

#Defaults for tftpd-hpa
RUN_DAEMON="yes"
OPTIONS="-l -s /var/lib/tftpboot"

Save the file if you need to make any changes and restart the daemon:

sudo /etc/init.d/tftpd-hpa restart

sudo nano /etc/inetd.conf

Edit the file so it looks similar to the following (note that you may need to change “udp” to “udp4” to override the default and use IPv4:

tftp    dgram   udp    wait    root    /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /var/lib/tftpboot

Once completed editing this file we need to copy the boot files from the Ubuntu ISO or CD.  In my case I inserted the Ubuntu Server CD into the machine’s drive and then completed the following:

sudo cp -r /media/cdrom/install/netboot/* /var/lib/tftpboot/

You can copy these files from wherever you’d like just as long as they end up in /var/lib/tftpboot/

At this point you should have everything in working order on the server side.  If your NIC has a boot menu for network boot (as some of my Intel NICs do) you can go ahead and try booting to the network.  If successful, it should retrieve the file from the server and then proceed to the Ubuntu Server installation screen.  If you want to customize your boot from this point (for example, retrieving the files from a local CD instead of over the Ubuntu mirrors via HTTP) see the Ubuntu guide listed earlier.

Client Machine Setup Using gpxe:

I found that I had better results using gpxe on the client machines.  I setup a boot floppy that included all of the NIC drivers by going to this website http://rom-o-matic.net/gpxe/gpxe-git/gpxe.git/contrib/rom-o-matic/ and choosing “all-drivers” and selecting a .dsk as the output format.  There are many different options you can chose as well if you would rather use USB or CD for example.  I created a floppy from this image using the following command:

dd if=IMAGE.dsk of=/dev/fd0

The example above assumes IMAGE.dsk is in the directory you issue this command from and also that your floppy drive is located at /dev/fd0.

This boot disk is quite useful if you are running into any issues.  It has a menu with a few setup and diagnostic commands.  You can manually set the server of which to direct once booted to this disk (if things don’t work for you automatically), change the target boot file, etc.

Troubleshooting:

Hopefully this gets those interested in PXE boot going successfully.  If you are having any problems, here are a few things to check:

• Check your DHCP server settings.  Ensure that the IP address and filename is correct.
• Check all of the configuration files edited earlier in this guide.  Any typos in the directory path will prevent things from working properly.
• Check that your PXE server is listening by issuing the following command:

  netstat -a | grep tftp

• Check that your NIC supports PXE boot
• Check that you have properly enabled network boot in BIOS

If I’ve missed anything feel free to contact me and I’ll add any additional steps for setup or troubleshooting to the list.

Squid3
Squid3 works as a web-cache proxy which means that while you browse, the content you are retrieving can also be cached for faster retrieval on the machine running the proxy – based on a set of rules in the proxy’s configuration files. This is not to say that ALL content gets cached, due to the fact that most content you are retrieving is dynamic, and it wouldn’t make sense to cache it due to the fact that you would quickly be viewing outdated material. In fact, in most environments only a small amount of content gets cached – which is why a web-cache proxy becomes more effective with more users working behind it. With a one-user environment the speed increase given by the cached content may not even offset the costs of running the proxy. With a multiple user environment there is most likely a significant amount of overlap in the viewed content and leads to the web-cache loading more of the local cached content versus retrieving new material each time. Although the amount of users on such proxies are not limitless as, due to the nature of a web-cache proxy, it will have to perform many reads/writes to its drives to receive and deliver cached content – and without adequate hardware to handle these read/writes, the network will actually suffer in performance as it will be bottlenecked by the proxy’s speed. If you have more questions about what exactly squid is and how it works checkout Squid’s site.

With all of this being said, the decision to implement a proxy on your network will need to be carefully examined by the needs and amount of throughput of the network. Keep in mind that Squid can be majorly tweaked to fit the needs of the network – so looking at the configuration options available is not something to be ignored.
Okay, enough with the explanations, on to the fun part – installation and configuration!

Target Setup:
There are many ways to setup Squid. The most simple is re-directing all traffic to a Squid box on the local network through your software. This requires simply adding the Squid box to the network and directing the web applications on the clients as needed. But those of us administering larger networks know that redirecting client browsers is a pain, and look toward a more automated solution. This was the reason I chose to setup this Squid box as transparent. It is transparent in the sense that no changes will be needed on the client-side for any network settings or re-direction in order for the proxy to be implemented. The diagram below illustrates this setup:

Diagram created using Gliffy

For clients, they have the following settings:

IP Address: DHCP (in the 192.168.2.0 subnet)
Gateway: 192.168.2.1
DNS: whatever you want, doesn’t affect this setup as long as they are working DNS servers.

The running Squid3 box will simply pass all traffic on eth0 to eth1 and vis versa, but will intercept all traffic on port 80 and re-direct it to the port that Squid is running on. From here, Squid will work its magic in either delivering the cached content to the client or retrieving it and then caching as needed. The client will have no idea where the content is being delivered from, and should ideally only notice it is being received quickly.

Installation:
I completed the following steps on a machine running Ubuntu 10.04 with 2 NICs installed (eth0, eth1). We will assume eth0 will be the incoming line from the gateway, and eth1 is the outgoing line to switch which the clients access (demonstrated in diagram).

sudo apt-get install squid3

That was simple enough… Most of the work is completed in the configuration.

Configuration:
We need to first add a few lines to the squid configuration file to make the proxy transparent.

sudo nano /etc/squid3/squid.conf

Add the lines below to the configuration:

http_port 3128 transparent
acl localnet src 192.168.2.0/24
acl localhost src 127.0.0.1/255.255.255.255
http_access allow localnet
http_access allow localhost

This next line is optional – it changes the default size for Squid’s cache to 5000MB to be stored in /var/spool/squid3.

cache_dir ufs /var/spool/squid3 5000 16 256

After making the changes above, save the configuration file and restart squid3. If there are errors Squid should fail to start.

sudo /etc/init.d/squid3 restart

I found ebtables easier to configure the bridge to pass traffic accordingly than iptables. You can use whichever you’d like.
Install ebtables and enter the lines below to pass traffic through accordingly. The port at which Squid is set to run by default is 3128, but if you have changed this in the squid configuration make sure and make the change in the rule accordingly.

sudo apt-get install ebtables
sudo ebtables -t broute -A BROUTING -p IPv4 --ip-protocol 6 --ip-destination-port 80 -j redirect --redirect-target ACCEPT
sudo iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j REDIRECT --to-port 3128

Also, enable traffic to be passed through both IPv4 and IPv6 on the local machine by uncommenting the following lines in /etc/sysctl.conf

sudo nano /etc/sysctl.conf
(uncomment the following)
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

You will need to install the bridge-utils to configure the bridge within your /etc/network/interfaces file.

sudo apt-get install bridge-utils

After configured my /etc/network/interfaces filled looked like this:

auto lo
iface lo inet loopback

auto eth1
iface eth1 inet static
address 192.168.2.199
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
gateway 192.168.2.1

auto br0
iface br0 inet static
address 192.168.2.200
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
gateway 192.168.2.1
bridge-ports eth0 eth1

Save this file and either reboot the system or restart networking and squid3.

sudo /etc/init.d/networking restart
sudo /etc/init.d/squid3 restart

After this go to one of your client machines and browse the web for a few seconds. You can then tell if squid3 is working correctly by checking the logs:

tail /var/log/squid3/access.log

This should show you the requests as they are received by squid3. Make sure and check traffic on other ports as well to ensure that it is being passed through correctly.
If traffic is not being passed correctly or squid is not logging any requests a good step to take would be to set the client machine’s browser proxy settings to direct right to the proxy. See if browsing is now working correctly. If so, squid3 is working correctly but there is most likely an issue with the traffic passing rules on the machine the proxy is running on.

Conclusion:

These were all the steps I completed to get my transparent proxy running successfully. Obviously you can tweak to fit your needs. The other added benefit of running the proxy in the “transparent” mode is that if the box fails you can simply disconnect the cable from the gateway to the proxy and plug directly into the client switch and the network will continue to function (obviously without local caching enabled).

Hopefully this helps others out there attempting to complete a similar setup. If you notice any errors with this tutorial please let me know. Thanks for reading.