@pwm@Tony@dsm@mint@Hoss pretty much how my shit works. redundant points of presence and caching at the edge, VPN tunnels back to the core router in my rack for cache misses/noncached data, and then routed to each virtual machine via NAT as required.
@Hoss@Tony@pwm@dsm@mint If josh came to me for hosting (lain.la or otherwise) I'd have to turn him down not even on principle but simply because the juice ain't worth the squeeze. That site is too damn hot to deal with, what with the fanbases it attracts both for and against. You pretty much need to angle yourself and your engineering exclusively for that market. It's a step beyond even just "bulletproof".
@dsm@Tony@pwm@Hoss i have so many projects in flight right now that providing services to others for free (or at-cost) off my personal racks is completely off the table for at least the remainder of the year. example: i bought a log cabin in a corn field and i'm trenching fiber to it.
if you're serious though, if you wanted to purchase some from nulled instead (which i'm helping to kickstart so it can carry lain.la traffic), let me know. i'd be your point of contact and would rack your shit with my bare hands in a real DC. i'm handling another nulled customer this weekend actually.
this is how i know y'all ain't paying attention. this shit DON'T WORK
here's why: say i enter a parameter of "1234.7z ". See that space at the end? That's the problem. If the file is "1234.7z" it won't exactly match "1234.7z " cause of the space. Adding wildcards before and after that incorrect string just makes it look for *1234.7z *. NOT *1234.7z*. therefore it doesn't match. this issue comes up because sometimes abuse report emails have spaces at the end of the filename being HTML emails and all.
now, the real problem here never had ANYTHING to do with a regular bloody space. It was what the space was MADE OF that was the real issue. When I do conversions of abuse reports into my fancy new "rmq" tool (essentially a wrapper for find), I just copy and paste the email data out, format it a bit, and paste it into my terminal. The key here is that I am doing the email reading and formatting on a WINDOWS machine, specifically notepad (find/replace is so easy in it). So guess what gets injected: A non-breaking UTF-8 space character! That's not a normal space at ALL! That has a totally different hexadecimal code! And your terminal won't show it unless you pipe it into something like cat -A which shows all the control codes. Look at this echoing of the command I ran:
echo rmq 6hu9hxxx.mp4 | cat -A rmq 6hu9hxxx.mp4M-BM- $
"M-BM- " was the culprit (the dollar sign just indicates the end of a line - also if you guessed CRLF fuckery here such as needing dos2unix - you get an honorable mention). And the best part was that in my "rigorous" testing of the tool, I was just using a regular ol' space in the command line which is NOT the same space as the copy/pasted space which explains why it worked in that case but not in the real-world use of the tool I wrote. This failure in testing is such an incredible case study on how your testing of software MUST replicate the EXACT steps you expect a user or a software program to take - or this shit happens!
So how do you fix this? Make sed deal with it and pass the results to your final command. My "rmq" tool now looks like this:
input=$1 trimmed=$(echo $1 | sed 's/\xc2\xa0/ /g') find . -type f -name $trimmed -delete -print -quit
one such penguin, the linux mascot, had this to say: "i don't know how my brethren will survive. we rely on $12 of yearly exports of ice and fish to provide for our families. now the forecasts predict $6 at most. we'll have to make cuts."