Ah, but developers should never had root on dev machines. Why you ask?
1. The dev enviroment MUST be the production environment. If they are different, things are going to break when you move new code to the production system. If I as the administrator allow these to become different I have failed my developers.
2. Developers have a tendency to start tweaking things they or anyone else in most cases have no business touching. My favorite example is the programming team who insisted that they needed more file descriptors because 100k wasn't enough. Our polite answer was, fix your broken code. Yes there are spscial cases to this and no this wasn't one.
3. All dev software should run as an unprivileged user. In customer apps there is no need for anything to be running on 1024 ports. This also makes it easier for the developers to make their own changes, restart their own server, etc. Now I have completed my responsiblity of ensuring I know exactly what is on the dev machine, that I can recreate in a reasoably short time, and allowed developement to continue at it's own pace.
Having apache run on port 8000+ in a dev enviroment is normal practice. In many cases you have mutiple developers on a single dev boxes running their own instances of Apache. Assuming the dev box is inside the firewall, where it should be, there should be no access problems.
Doing the same thing in production is less common, but with the hardware mentioned, it's trivial and completely transparent to end users.
Chasing Amy? Nah, Afflect will always be rememberd by me as "the proprietor of Fashionable Make" who often tkes advanagtes of females "in a very uncomfortable place"... no not a Volkswagon.
oh look it's 2003 and this Postfix bug FROM WAY BACK 1998 must still be relevent... unlike qmail, Postfix has active developement and doesn't require 3 extra packages and 45 patches to do useful things.
And before you ask I was an admin on one of the largest qmail installations on the net, 10 Tb backend.
The point is it didn't take anything down... nope not even close. The Washington Post could have well said "Grandma Smith sends 10 icmp packets to cable modem" and it would have been just as "damaging".
Except that they didn't invent grunge or alternative music. It was a slightly different take on what people had been doing for years. If anything they copied others and got to make all the money. Should Nirvana have to kick back to the Pixies and Sonic Youth for what they wrote?
Except this is a large system we're talking about. Who has just one mail server anymore?
Yeah multiple CNAMES is supposed to work in Bind 9.x, but I'd look at interoperatably before I impletmented it.
Then you get into the same problems. pop is CNAME'd to suzi, shannon, kelly, and laura... that doesn't make anything easier to understand at first glance.. or scale.
Moving a machines from one service to another without doing all these is also silly. I want an admin to have to check the machine out and not just move it whith who know what still running on it.
The easy way is to have images for all your major server, which most companies do. If you don't you're on crack.
When I get called at 3am after a dinking binge i need to do as little thinking as possible. www-001 went down requires little such thought. Also NOC techs actually have some idea what that might break. When the "megatron" goes down and users stop authenticating leave it to a NOC tech not put two and two together.
I worked at a major ISP as a Network engineer and had 600 machines over 14 geogrphic locations.
1. Subdomains Pick a name per site that make sense. Lots of people use airport codes. That worked well for us. Sometimes though CHI is that much more readably then ORD (Ohare airport).
2. Easy descriptive names www-001 www-002 Notice that this will sort correctly with that extra interger. Always assume that you will have more then 10 server of a particular kind.
3. More subdomains service-001.customer.sub.domain.tld
4. Put it in writing Tell staff they are not allowed to deviate from this. Ever.
5. Enforce DNS Putting a machine on the network without DNS was written warning about the future of your job.
You're still wrong. Ethernet doesn't guarantee bandwidth... there's just usually more of it. This has nothing to do with protocol.
If you don't want lag, don't go over the net. IPX is routable though no does it on the Internet at large. Hell I'll even encapsulate it in TCP and spit it out on the other end for you. There is no reason to run any other protocol other then TCP unless you're bored or TCP is unsupported/broken. Considering more people have TCP/IP running by default I find it hard to beleive that it's a problem to setup at a lan party or otherwise.
kashani, who once ran THE largest Tribes 2 server where the FastEther port on the server was the slowest part of the uplink.
Maybe you should start attending those far off ICANN meetings. ICANN is fucked. The process is fucked. And the rest of use are fucked if it doesn't change soon.
The point was we don't don't need the assorted bullshit that comes with ICANN. We need technical know how to tweak a system the could work really well.
Yeah I'd trust ICANN to run a root server. Hardly.
You just need to know how to word your change tickets to get management to sign off quickly. Something like:
"IOS upgrade on our router tonight to a version that won't blowup at some indeterminite point in the next 3 days (see Cisco bug ID 613224). Outage time 5 minutes.
If this change is not done the router will crash by Friday and will invlove much more downtime, choas, and looting in the streets."
That's almost verbatim of a recent change ticket... well except for the part where I quoted the Cisco bug ID #.:-)
But this is the point of the CSS 11801 Slashdot bought. You can load balance based on URL, extension, port, whatever. So images should get served from the image farm which should have enough RAM to server images from cache and run the OS, but not much more. Db servers would need more disk and RAM depending what you're doing. And so on. Purpose built hardware/software can do wonders for scaliblity. Tux is a good example of that thinking. Let all static info get served off it and the dynamic happen at other points.
Read the Nanog posts again. Cutting off peering to a provider that has no transit mean they can't see each other. Period. Unless one of them would like to pay for transit.
Is there any such week where IT doesn't get attacked? I thought that's why we got paid the big bucks? Outlook viruses, RIP left on on the firewall and gated started, bad firmware, cut fiber, BGP flaps, IIS worms, named worms, DOS attacks, need I go on?
Exodus is a fucking pain in the ass. Don't even bother. You'd think if you're building 1000 sqft of space you'd get some respect? Hardly. They screw up everything, refuse to fix it, tell you you ordered it wrong, and got to great lenghts to tell you how much better they are then the comptetion and how most of the people working there have their MCSE. I couldn't contain myself after that. I've got 3 other colo spaces with 3 other providers. Exodus is the wortst. Overpriced idiots.
We need dynamic routes so that we can actually pass traffic when links fail. Link go down, route gets dropped. Router crashes routes get dropped. Also have you ever tried to static route 100K routes?
Slashdot Mirror
snoop,tcpdump,reboot?
This is why there is sudo.
kashani
Ah, but developers should never had root on dev machines. Why you ask?
1. The dev enviroment MUST be the production environment. If they are different, things are going to break when you move new code to the production system. If I as the administrator allow these to become different I have failed my developers.
2. Developers have a tendency to start tweaking things they or anyone else in most cases have no business touching. My favorite example is the programming team who insisted that they needed more file descriptors because 100k wasn't enough. Our polite answer was, fix your broken code. Yes there are spscial cases to this and no this wasn't one.
3. All dev software should run as an unprivileged user. In customer apps there is no need for anything to be running on 1024 ports. This also makes it easier for the developers to make their own changes, restart their own server, etc. Now I have completed my responsiblity of ensuring I know exactly what is on the dev machine, that I can recreate in a reasoably short time, and allowed developement to continue at it's own pace.
Having apache run on port 8000+ in a dev enviroment is normal practice. In many cases you have mutiple developers on a single dev boxes running their own instances of Apache. Assuming the dev box is inside the firewall, where it should be, there should be no access problems.
Doing the same thing in production is less common, but with the hardware mentioned, it's trivial and completely transparent to end users.
kashani
Chasing Amy? Nah, Afflect will always be rememberd by me as "the proprietor of Fashionable Make" who often tkes advanagtes of females "in a very uncomfortable place"... no not a Volkswagon.
kashani
Except that it's not faster. In our tests 8.x was faster then 9.x and djbdns in handling 1000+/s requests on Solaris, BSD, and Linux.
kashani
oh look it's 2003 and this Postfix bug FROM WAY BACK 1998 must still be relevent... unlike qmail, Postfix has active developement and doesn't require 3 extra packages and 45 patches to do useful things.
And before you ask I was an admin on one of the largest qmail installations on the net, 10 Tb backend.
kashani
The point is it didn't take anything down... nope not even close. The Washington Post could have well said "Grandma Smith sends 10 icmp packets to cable modem" and it would have been just as "damaging".
kashani
Hey how would people feel about meeting at the Diversy Rock and Bowl, 2211 West Diversey.
1. Bar
2. Darts
3. Air Hockey
4. Arcade
5. Rockabilly Waitresses
6. Second Bar
7. Bowling
kashani
Don't worry I'll pass this little blackmail friendly post on the fabulous Miss JJ. heh heh.
I still think we should have an Onion meetup.
kashani aka Ramin
You should check out John Stakely's _Armour_ if you liked Forever War. Similiar themes and well written.
kashani
Except that they didn't invent grunge or alternative music. It was a slightly different take on what people had been doing for years. If anything they copied others and got to make all the money. Should Nirvana have to kick back to the Pixies and Sonic Youth for what they wrote?
Silly Cobain worhipping moron.
kashani
Except this is a large system we're talking about. Who has just one mail server anymore?
Yeah multiple CNAMES is supposed to work in Bind 9.x, but I'd look at interoperatably before I impletmented it.
Then you get into the same problems. pop is CNAME'd to suzi, shannon, kelly, and laura... that doesn't make anything easier to understand at first glance.. or scale.
kashani
Moving a machines from one service to another without doing all these is also silly. I want an admin to have to check the machine out and not just move it whith who know what still running on it.
The easy way is to have images for all your major server, which most companies do. If you don't you're on crack.
When I get called at 3am after a dinking binge i need to do as little thinking as possible. www-001 went down requires little such thought. Also NOC techs actually have some idea what that might break. When the "megatron" goes down and users stop authenticating leave it to a NOC tech not put two and two together.
kashani
I worked at a major ISP as a Network engineer and had 600 machines over 14 geogrphic locations.
1. Subdomains
Pick a name per site that make sense. Lots of people use airport codes. That worked well for us. Sometimes though CHI is that much more readably then ORD (Ohare airport).
2. Easy descriptive names
www-001
www-002
Notice that this will sort correctly with that extra interger. Always assume that you will have more then 10 server of a particular kind.
3. More subdomains
service-001.customer.sub.domain.tld
4. Put it in writing
Tell staff they are not allowed to deviate from this. Ever.
5. Enforce DNS
Putting a machine on the network without DNS was written warning about the future of your job.
kashani
You're still wrong. Ethernet doesn't guarantee bandwidth... there's just usually more of it. This has nothing to do with protocol.
If you don't want lag, don't go over the net. IPX is routable though no does it on the Internet at large. Hell I'll even encapsulate it in TCP and spit it out on the other end for you. There is no reason to run any other protocol other then TCP unless you're bored or TCP is unsupported/broken. Considering more people have TCP/IP running by default I find it hard to beleive that it's a problem to setup at a lan party or otherwise.
kashani, who once ran THE largest Tribes 2 server where the FastEther port on the server was the slowest part of the uplink.
Maybe you should start attending those far off ICANN meetings. ICANN is fucked. The process is fucked. And the rest of use are fucked if it doesn't change soon.
The point was we don't don't need the assorted bullshit that comes with ICANN. We need technical know how to tweak a system the could work really well.
Yeah I'd trust ICANN to run a root server. Hardly.
kashani
You just need to know how to word your change tickets to get management to sign off quickly. Something like:
:-)
"IOS upgrade on our router tonight to a version that won't blowup at some indeterminite point in the next 3 days (see Cisco bug ID 613224). Outage time 5 minutes.
If this change is not done the router will crash by Friday and will invlove much more downtime, choas, and looting in the streets."
That's almost verbatim of a recent change ticket... well except for the part where I quoted the Cisco bug ID #.
-kashani
John Brunner's Shockwave rider would be a better book to read for this. Written in the early 70's. Worldwide data nets and worms attacking data.
-kashani
You'd probably want to check out Ultra DNS. They licensed their software to us though I'm not sure if they do it anymore.
Oracle backend
non blocking nameserver
It was pretty bad ass.
-kashani
But this is the point of the CSS 11801 Slashdot bought. You can load balance based on URL, extension, port, whatever. So images should get served from the image farm which should have enough RAM to server images from cache and run the OS, but not much more. Db servers would need more disk and RAM depending what you're doing. And so on. Purpose built hardware/software can do wonders for scaliblity. Tux is a good example of that thinking. Let all static info get served off it and the dynamic happen at other points.
kashani
Or you can just become one of the Admin's at your ISP. :-) Besides ISDN was so much cheaper when your company is comping it for you.
kashani
Is True.
Read the Nanog posts again. Cutting off peering to a provider that has no transit mean they can't see each other. Period. Unless one of them would like to pay for transit.
kashani
Is there any such week where IT doesn't get attacked? I thought that's why we got paid the big bucks? Outlook viruses, RIP left on on the firewall and gated started, bad firmware, cut fiber, BGP flaps, IIS worms, named worms, DOS attacks, need I go on?
kashani
Exodus is a fucking pain in the ass. Don't even bother. You'd think if you're building 1000 sqft of space you'd get some respect? Hardly. They screw up everything, refuse to fix it, tell you you ordered it wrong, and got to great lenghts to tell you how much better they are then the comptetion and how most of the people working there have their MCSE. I couldn't contain myself after that. I've got 3 other colo spaces with 3 other providers. Exodus is the wortst. Overpriced idiots.
kashani
Ahem.
/32 is one IP address.
/64 is 18446744073709551616 IP addresses
with 32 bits a
with 128 bits a
DO you have any idea what you are talking about?
We need dynamic routes so that we can actually pass traffic when links fail. Link go down, route gets dropped. Router crashes routes get dropped. Also have you ever tried to static route 100K routes?
kashani