Archive

Archive for March, 2010

Setup sflow on a Juniper EX switch for WUG

March 15, 2010 2 comments

Here are the steps to setting up a Juniper EX-3200 series switch to send sflow data to WhatsUp Gold (WUG) Flow Monitor. Technically its the same for procedure for any flow monitor, I’m just doing it for WUG in this instance.

  1. Log into the switches CLI.
  2. Enter edit mode by typing “edit” and hit “Enter”
  3. First the SNMP community must be set. This will be set as read only, in this instance I do NOT want WUG to have configuration capabilities.
    1. Type: set snmp community sflowtest authorization read-only
      1. **Replace “sflowtest” with the community name you wish to use.
      2. Also make sure this community name has been added as a credential in WUG.
  4. Now we will enter the collector information:
    1. Type: set protocols sflow collector 10.1.1.2 udp-port 9999
      1. Change the ip address 10.1.1.2 to the IP address of the WUG flow collector.
      2. By default WUG collects sflow data via udp-port 9999, which is not the default UDP port used by Juniper.
    2. Now to change the default polling interval to 10 seconds and sample rate to 500.
      1. Type: set protocols sflow polling-interval 10 sample-rate 500
    3. Finally set the interfaces you want flows collected from:
      1. Type: set protocols sflow interfaces ge-0/0/12.0
        1. Do the above for each interface you need flows collected from.
  5. Now commit the changes:
    1. Type: commit check
      1. Even though this was a simple configuration I ALWAYS do a commit check!!!
    2. Type: commit confirmed 1
      1. Again, even on simple configuration changes I play it safe. If the changes I am about to commit do cause a problem they will be rolled back in one minute.
    3. Type: commit
      1. Finally I do a commit before the one minute time is done.
  6. If you wait a minute or two you should see the switch show in the WUG Flow Monitor.
  7. In the WUG Flow Monitor you may have to go into the source properties and put a check in  “Collect data from this source”.
Advertisements
Categories: Juniper, Networking

Facebook game filters broken-ish?

March 12, 2010 1 comment

As many have notified me, the Facebook game filters appear to be broken. They are not actually completely broken. The first few items in the filter are showing anything from your live feed. However if you scroll down to show older posts it will show the correctly filtered items.

My speculation (that’s all it is) is that Facebook is trying to get rid of the filters altogether. They have been trying to get rid of the filters and push people to the worthless games console.

Categories: Facebook

PDF sent from MUTT not seen as attachment in webmail

March 11, 2010 4 comments

Recently I had a report from a user that PDF’s sent from MUTT were not visible from the webmail used by their recipient. I thought this was odd because the very reason I changed from mailx to MUTT was so I could use MIME instead of UUENCODE, thus insure all clients could read attachments.

I verified some of the common webmail clients could receiv a PDF correctly: Hotmail, Yahoo Mail, GMail. All of the before mentioned services worked fine. It was then I was able to get the recipients email address, it was a Charter account. This is not the first time I’ve had problems with Charter receiving email. I’m not sure what Charter users for its webmail, but it seems to be worse bit of code I’ve ever encountered for email usage.

Charter accounts are able to view PDF’s sent from Outlook and other clients. What I found is that MUTT sends all emails with the following set in the header:

Content-Disposition: inline

With further testing I found that no matter what is attached to the email Charter will interpret the whole email as one long text file. The content disposition is not user editable in MUTT, and has been confirmed in their bug tracker as a new enhancement.

There is a patch someone created to fix this (for PGP, but works for this as well). However it looks like the MUTT project group is unlikely to change the default behavior because according to the RFC the client software should be able to detect attachments correctly no matter what (this is very over-simplified, read the RFC if you want a longer explanation).

My solution in this case to ignore the problem. With only one recipient being affected it did not warrant time/resources to find a solution. After knowing about the problem we were able to get the customer use a client instead of webmail.

Categories: UNIX

Set the display name in Mutt

March 11, 2010 3 comments

A while back I posted instructions on how to use MUTT to send email attachments and specify from address. This is an addition to that post.

The previous instructions work good. The only problem I have run into is the “real” or “personal” name of the sender.  One of my users noticed that emails sent out would show their username in the recipients mail client. To fix this I had to set another variable: realname.

Here is an example of the original code I used:

mutt -e ’set from=fromaddress@test.com’ -s ’subject’ -a file.pdf toaddress@test.com < body.txt

Here is an example of the new code including the set realname:

mutt -e ’set from=fromaddress@test.com realname=”Test User”’ -s ’subject’ -a file.pdf toaddress@test.com < body.txt

As you can see I put the variable after the set comand just like the from variable. The quotes are only neccesary if there is a space in the realname. Here is how the from field shows in a mail client now (Outlook 2007 in this case):

Test User [fromaddress@test.com]

The first part of this is what was set using the new code. If this is not specified MUTT will populate the real name from the GCOS field in /etc/passwd.

Chapter 6 of the MUTT documentation has greater detail for command line options.

Categories: UNIX