Posts made by anthonyh

We run MSSQL on VMs under XenServer. We have two pretty hefty MSSQL VMs, and I have them configured so that TempDB, User DBs, Logs, and backups are all on their own virtual disks. These virtual disks all reside within the same SR, which is a virtual volume on our 3PAR SAN. Each MSSQL server is given it's own virtual volume.

I grow the respective virtual disks as needed, as well as the virtual volume. It has worked out well in our instance. If we didn't have the flexibility the 3PAR "virtual volume" model, I would probably be approaching this differently.

As for the "number of TempDB files per logical processor", I have this implemented on our two large production MSSQL servers. Whether or not it improved performance I cannot say for fact. I can tell you that it did not cause any harm for us. I have 8 TempDB files that are of equal size (since the rule of thumb is to not exceed 8 if you have more than 8 logical processors), and I grow them as needed. I believe there is a trace flag that you can set (in 2012 anyway) that will make auto-growth grow all files evenly, but I'm paranoid and handle it manually.

https://support.microsoft.com/en-us/help/2154845/recommendations-to-reduce-allocation-contention-in-sql-server-tempdb-database

Of course, every MSSQL environment is different. So your resulst may vary.

@scottalanmiller Ha. Well, it took me posting the question to the official SpamAssassin listserve before seeing my mistake. I caught it as soon as my message posted. A quick reply-of-shame, then an update of this thread.

And I can officially confirm that my rule now works exactly how I expect it to.

Who would've though you had to type things correctly...

Fitness FTW!

Over the years I've had my ups and downs with weight, my highest being 285 lbs. Last summer I joined a gym and started to pay more attention to what I ate and how much I ate. Before I started this, I was 230-240 ish. I'm happy to say I'm a decent 197 lbs as of this morning (I'm 6' tall FWIW). It's great!

"Number-on-a-scale" wise I think I'm good. At this point I want to work on toning up a little. I've still got more fat around my mid section than I'd like (significantly less than in the past, though)...and I don't drink beer. My wife says that a good portion of it is loose skin. Hopefully I can improve on it.

Holy crap! Am I an idiot or what?! The issue is my score line. It's wrong. It should be:

score  AH_KNOWBE4  -10.0

Not sure why the hell it took me so long to catch my mistake!

@dbeato said in Zimbra - Export List Of Distribution Lists:

You can also export your DLs to a document file too
zmprov gdl > dist-list

That's essentially what I did.

We've signed up with KnowBe4 and are currently running phishing campaigns against a small group of test users (basically the IT department). Since folks have been marking the messages as spam (which is good), SpamAssassin has learned this and is now starting to automatically catch the phishing campaign emails and direct them to the user's Junk folder.

I threw together a basic rule to help reduce the message score. Here is the rule:

header AH_KNOWBE4   Received=~ /phishtest\.knowbe4\.com/
score AH_KNOWBE4    score -10.0
describe AH_KNOWBE4 Prevents KnowBe4 campaign emails from falling into users Junk folders

The rule is being triggered. However, instead of applying the score of -10, a score of 1 is applied. I'm not sure why.

For what it's worth we're running Zimbra 8.6.0

What am I doing wrong?

Well, crap. I think I answered my own question...

[zimbra@mail ~]$ zmprov gadl

Does the trick

This one should be easy, I think...

What is the easiest way to export a list of distribution lists? I don't need the members. I just need the lists themselves.

Thanks!

Well that was a fail. The append function was not what I thought it was. It's for elements within the XML file, not the value of a given element. Arg. Hmm...

@scottalanmiller said in XMLStarlet - Argument List Too Long:

Oh, it is READING the PDFs into the command? I see.

Yep. Sorry for not making that clear.

I think I may have a solution...I haven't tried it yet though. It looks like I can append a value to an element. What I'm going to try is splitting the base64 in half and doing two operations. First, I'll update the element with the first half of the base64, then I'll append the element with the second half of the base64.

Here goes nothing...

@scottalanmiller said in XMLStarlet - Argument List Too Long:

Any chance that your command is out of order? Move the ed bit to the next to last thing, just before the file name.

The command structure itself is good as far as I can tell. When my script churns through 20 or so XML files, it only bombs on the larger PDFs. The smaller PDFs (2 page docs) it works great.

This is the loop that churns through the documents that are ready to process:

Works great on the smaller PDFs (2 page docs). On the larger PDFs (18 pages) is where line 38 bombs with "Argument list too long".

The length of the command when processing the 2 page PDFs is in the 43000 range. The length of the command when processing the 18 page PDFs is in the 150000 range which is greater than the size of the command buffer being used.

@scottalanmiller said in XMLStarlet - Argument List Too Long:

Isn't the command xml not xmlstarlet?

http://xmlstar.sourceforge.net/doc/UG/xmlstarlet-ug.html

In all the documentation I've ready, yes. However, in my installation (which was a simple yum install xmlstarlet), "xml" does not work.

I think I may be on to something, or I may be going down the wrong rabbit hole...but here it goes...

If I run "xargs --show-limits", I get:

Your environment variables take up 1953 bytes
POSIX upper limit on argument length (this system): 26210399
POSIX smallest allowable upper limit on argument length (all systems): 4096
Maximum length of command we could actually use: 26208446
Size of command buffer we are actually using: 131072

When I get the length of the command when it fails, its length is 154299. This is larger than the 131072 command buffer.

Is there a way to bump up the command buffer size?

Hey All,

I'm using XMLStarlet to work with XML files we process with a partnering agency. Basically, we receive an XML file that contains a base64 encoded PDF. We consume the XML, process the document, then return the document to them.

The process I have put together via a BASH script so far was working out great. However, I just hit a roadblock. I've been testing with the smaller documents (2 page documents). Yesterday I decided to test with one of the larger documents (18 pages). When I go to insert the processed base64 into the XML file, the command bombs.

Here is the command:

xmlstarlet ed -L -u "/efile:EFilingData/cse:DocumentBinary/cse:BinaryObject.Base64" -v "$stampedBase64" $workingDir/$fileName

Here is the error:

/usr/bin/xmlstarlet: Argument list too long

I'm pretty confident the reason is because the $stampedBase64 of an 18 page PDF is a shit-ton long, which means I'm hitting some sort of command length limit of some sort.

Is there any way around this limitation? Is there a way I can feed it a value from a file?

For what is' worth the script is running on a CentOS 6 VM.

I run Fedora on my primary desktop at home and just updated to kernel 4.10. NVIDIA's later driver has a bug that causes it to fail to compile with this kernel. Posting the workaround in case anyone else runs into this issue.

Source: https://devtalk.nvidia.com/default/topic/995429/failed-installed-nvidia-with-kernel-4-10/

Extract the installer:

sudo chmod +x ./NVIDIA-Linux-x86_64-375.39.run
./NVIDIA-Linux-x86_64-375.39.run -x

CD into driver directory and download patch:

 cd ./NVIDIA-Linux-x86_64-375.39
 wget https://pkgs.rpmfusion.org/cgit/nonfree/nvidia-kmod.git/plain/kernel_4.10.patch

Apply patch:

 patch -p1 < kernel_4.10.patch

Run the driver installer:

sudo ./nvidia-installer

Driver should install successfully!

@FATeknollogee said in Where Are You Running Nextcloud:

Even at 10 secs, it is/was way, way faster than the A2 service.

True, and from what I've read here there are restrictions/limitations to A2 that make it even less attractive to use.

If the 196 MB file was truly "downloaded" and not cached, then you were receiving a transfer rate of 1568 or ~1.5 Gbps. Unless you have more than 1G of bandwidth between you and your ISP....

@FATeknollogee said in Where Are You Running Nextcloud:

Downloading the 196MB file:
Vultr: 1 sec
A2: 1 min.

reference: My FIOS connection is 150/150

How did you download 196 MB of data in 1 second? 150 Mbps, if my math is right, is ~18 MB/sec. Do you mean 10 seconds? Does FiOS do some sort of temporary bursting above your subscription rate? I'm merely curious.

@travisdh1 I may have to check that out. Though, I think if I was do something to "anonamize" (sp?) my browsing history I'd want to do it at the network level so my family is included. I'll have to look into Tor and/or VPN routers and see what's out there.

Woot!