brent's questions

How can I configure a persistent ip rule on Linux (specifically Redhat based distros)? Is there no built in method? Is my only option adding to /etc/rc.d/rc.local or creating my own rc.d script?

Edit: For clarification I am not referring to iptables but the ip tool (which I don't think a lot of people are familiar with). In any case, the rule I am trying to persist is added with the following command:

# ip rule add fwmark 1 lookup 100
# ip rule
...
32765: from all fwmark 0x1 lookup 100
...

The only reference I've found to doing this is from Novell: http://www.novell.com/support/viewContent.do?externalId=7008874&sliceId=1 which recommends creating an rc.d script

I had a Citrix XenApp 6.5 sever running smoothly in a very simple domain (one DC, one XenApp server) until the XenApp server had to be restarted recently. After it came back, applications can no longer be launched from a Receiver.

In the Event logs I can see:

A usable server cannot be found on which to launch the application. 

The Citrix servers reported that they are too busy to provide access to the selected resource. This message was reported from the XML Service at address ...

Running qfarm displays no servers. Running qfarm /load shows my one server (which is local to where qfarm is being executed) at 100 load. I have checked the license server and there are no errors

Edit: Executing

net stop imaservice
net start imaservice

Allowed the server to show up under qfarm, but load was initially at 10000. It eventually went back down to 100, and applications were able to be launched. The issue appears to be connected then to the server showing up there, and I have a hunch that it's network/DNS related as qfarm /addr HOSTNAME was not returning an IP previously, but is now. This was also reflected in AppCenter

I'm going through the initial configuration of Citrix XenApp 6.5. I have two servers, a DC and the XenApp server.

I created an OU XenApp, and a user "ctxadmin" on the DC. When configuring the XenApp farm I specific the admin user as DOMAIN\ctxadmin. Now when I'm logged in as Administrator and launch AppCenter, it says:

This user account is not an administrator of this farm, or there was a problem contacting the data store. Check that the data store server for the Citrix XenApp farm is online, and verify that your account is configured and enabled as an administrator on the farm.

If I log into the server as ctxadmin I cannot launch AppCenter without putting in the Administrator credentials, and then discovery doesn't work.

I seem to be in an endless loop. How can I fix this?

I have a process being started on my server that appears to modify what ps/top sees, so I don't know the filename or the path of it since it's hiding it (it's a perl script). How can I track down where the file is on disk?

I administrate an email system for a commercial ISP. I'm currently having an issue with one of our customers relaying outbound SMTP traffic from their Exchange system through ours, and they're generating NDRs and other failure messages in response to spam. I need them to stop doing this, however their own admin is not very savvy. I'd rather provide them some guidance than leave them blocked from using our relays.

Having never worked with Exchange (I'm a *nix/BSD guy), is there some way they can accomplish this without other software or hardware in front of it? I've looked at the header content and they are scanning for spam, which is adding an X-* header which identifies the message as such. Can Exchange outbound filter this?

Does anyone have any other ideas on stopping these NDRs before they ever get to our servers?

I have an HS22 blade configured with two 600GB 10K 6Gbps SAS drives configured in RAID1 using the onboard LSI Logic controller. Running on it is VMWare ESXi 4.0u2, and on top of that are a couple VMs. (Yes, I'm aware that we should be providing storage via SAN, but this was a budgetary constraint) I'm seeing poor read/write performance

• Host A: RHEL 5.5, 8GB RAM, 2 vCPUs
• Host B: CentOS 5.5, 1GB RAM, 2 vCPUs

Both kernels are configured to boot with elevator=noop

Result of ~8GB dd on Host A to a 350GB thin-provisioned disk, ext3 formatted:

# dd if=/dev/zero of=fullram bs=1K count=8388608
8388608+0 records in
8388608+0 records out
8589934592 bytes (8.6 GB) copied, 467.934 seconds, 18.4 MB/s

The maximum write performance I've seen is ~30MB/s (monitored through vSphere client)

Result of ~8GB dd on Host B to a 40GB thin-provisioned disk, ext3 formatted:

# dd if=/dev/zero of=fullram bs=1K count=8388608      
8388608+0 records in
8388608+0 records out
8589934592 bytes (8.6 GB) copied, 478.192 seconds, 18.0 MB/s

The maximum write performance I've seen for this VM however is about 50MB/s (monitored through vSphere client)

I've tested read performance on Host A in the following way:

1. dd a 1GB file
2. dd a second file to the same size as RAM (8GB)
3. Read the 1GB file with dd

Result was:

# dd if=testfile of=/dev/null bs=1K
2097152+0 records in
2097152+0 records out
2147483648 bytes (2.1 GB) copied, 190.255 seconds, 11.3 MB/s

I'm at a loss for what could be causing this issue

Is it possible to configure a Cisco switch running IOS via SNMP? I know there is a method for initiating a TFTP copy via SNMP (doc), but is there something like port level config directly from SNMP writes?

Alternatively, is there a way to initiate transferring a configuration snippet to apply, rather than replacing the entire configuration?

Let me know if you'd like anything clarified. I'm trying to avoid using Expect or anything that is not similar to accessing an API.

I'm curious what the actual effects of the L root server publishing DURZ today will be. On the nanog mailing list, someone said it's important to evaluate the systemic effects of root name servers publishing signed zones, even when not using DNSSEC. Meanwhile, RIPE's own published information on their changes to the K root server say there's no issue if your resolvers don't use DNSSEC. Can someone please clear this up? DNSSEC seems to be a messy, tangled web.

If not enabling DNSSEC on my resolvers, do I have anything to worry about with the upcoming changes to the root servers?

I'm trying to figure out how this issue is occurring and how to stop it. Somehow messages are getting into our inbound Exim spool without any \n at the end. When our outbound Exim process tries to deliver these mails, they fail as Exim outputs '.' on the same line as the one it just sent. I've verified this by capturing the SMTP conversation from both sides with tcpdump

tcpdump shows the following being sent at the end:

<!--www.https://example.com--><!--www.https://example.com-->.

Which is not a proper termination of DATA. Eventually the receiving MTA responds

421 Lost incoming connection

Passing the message in the spool through od, I see at the end of the message body:

0011700 e . c o m - - >

No \ns. These messages getting stuck in the spool seem to only ever be spam. What I see in the outbound log,

1NLolk-0003aD-3V == [email protected] R=Storage T=Storage defer (-46): SMTP error from remote mail server after end of data: host 192.168.1.3 [192.168.1.3]: 421 mda.local SMTP incoming data timeout - closing connection.

Does anyone have any ideas? The "message_suffix" parameter sounded like it would have been a good bandaid, but it only applies to appendfile and pipe.