A load balancer does not give redundancy. With a load balancer, if a server dies, NEW connections are sent to a different server instead, but the existing connections to the down server all are closed - an external non-OS integrated solution like load balancing does not give transparent failover on TCP connections. It works for HTTP because browsers are used to connections suddenly dieing and will simply retry. But, if the client isn't smart enough to reconnect, it won't work.
The way to do this is to build a custom TCP stack and integrate it tightly into your app. A lot of work and hard to get right.
I would ask, "Do we REALLY" need this when our application already has to handle things like network failures? You might, though - I don't know what your application is.
Also, don't forget to use redundant routers, redundant firewalls, etc. If you use NAT, that imposes one more problem - transparently moving the connection table between the failed firewall and the working one.
1) Use some sort of encryption-related technology, like MACs (see my other post)
2) Use some sort of phased array receiving antenna. These can select what direction to listen to a request from. That means that someone would have be in your geographic area or have an EXTREMELY strong antenna (much stronger then yours) to do any sort of DOS or even send legitimate commands.
I do PKI for a living. Actually, in this case, it might not be the right choice.
Do you really mean PKI or simply Public Key Encryption? Do you actually picture a root certificate authority, subordinate certificate authorities, directories, certificate revocation lists, and authority revocation lists being used to secure a satellite's command & control?
PKI is a great choice when you have lots of parties that need to randomly communicate with each other. It provides a great key distribution. However, PKI seems like overkill when one (or, at most, two) ground stations will be talking to a satelite. In this case, distributing a shared secret really isn't that difficult - probably much easier then building a PKI network and keeping it secure! Of course it does depend on if you trust your internal computer systems to keep the key private. If you don't, then PKI might solve some of your problems.
I would suggest a very lightweight approach. Privacy of data is not required for this application, IMHO. Maybe I'm wrong, in which case, you should investigate other options. This sounds like a good case for a MAC (Message Authentication Code). You don't even need to use encryption - just hashing - to do this.
Basically, each end has a shared secret, "S".
You have a packet containing data, "D".
Each packet has a timestamp (to prevent replay attacks) "T".
All packets consist of: D+T+MD5(D+T+S)
Of course, you can use some sort of hash besides MD5. You can also program the satelite with a few thousand secrets, which expire every so often - if you give it 100 years of secrets at launch, you should be fine.
The satelite receives this packet, does the MD5 of D+T+S, and compares the numbers. It doesn't let you use a packet with an old T (T should be very close to the current time and T should be greater then the most recent T).
This code has the benefit of taking very little memory space compared to a PKI solution. It's also much easier on the uplink/downlink channels.
The most important thing to remember, though, is that this shared secret has to be kept secret. It should not be used by your normal programmers to write control software. Instead, it should be an external module that runs on a secure box (I.E. no remote administration capabilities, only allows connections via a secure interface, and adds on the MAC as the messages pass through it). If you can afford a satellite, you can afford one secure server! I would definately investigate commercial encryption devices which add on a MAC using a shared secret - at least on the ground-station end. They of course may function differently then the method I described above, but the basics remain the same.
Of course all of this has been solved before. ATMs and banks have long needed to authenticate the other end. (ATMs, BTW, do not use public key cryptography, but simply a split key pair - that is, a random string of numbers is one part of the pair and that string XORed with the real key is the other pair - each part is given to a different person who keys it into the ATM seperately from the other person - you might also incorporate this type of system). Since this has been solved before, I recommend that you hire some sort of encryption expert to help you (you are NOT looking for a computer security person - chances are you are not running a default install of W2K on your satellite!).
As for IP, I would think that you would want to ensure there was no way for someone outside the control room to use your equipment to send command and control messages to your satellites! At the very least, this means that the control room should probably have an air-gap between it and the rest of your network. Sure, a little inconvienient, but how much command and control data do you really have to share with people outside that room? Not much most likely - certainly not too much to retype.
Almost every story here seems to be, "Waaaaaa! I can't get foo for free!!! Waaaaa!"
First, there is griping about the "broadband monopoly". Apparently, for $25/month, we are entitled to buy broadband when our usage will cost the company more then they will make. Strange, I know, but people here just don't get it - companies exist to make money. Apparently, if I'm the only person making a particular product, I'm obligated by "monopoly" to sell every version of it imaginable for the price that Slashdot thinks I should.
As for this software piracy, the real issue is that people don't want to pay for software. It isn't anymore complicated then that. They have very complicated justifications, but they don't want to pay for thier software. Fine, don't. But don't use it, either.
I think the biggest thing that could be done for open source software would be an enforcement of piracy law. Think about it - how many people would keep using Word at home if they had to pay for it? Don't you think that it might help some of the OSS word processors get market share? But, no, we're whining about how we should be able to use Windows and Word for free. Even the Slashdot community, who is supposed to be pro-OSS, seems to think that commercial software is better then the alternatives (at least for some things). If we don't believe what we preach (that OSS is best), then how can we expect others to?
After all, doesn't the music theft crowd believe that piracy increases the sales and populatiry of music? Why, then, would we pirate software on the moral grounds that the company doesn't deserve our money? Our piracy may contribute to the company's bottom line.
What kind of problems are you having? Because you mentioned large organizations, I'm assuming you are talking about problems with large-volume web server farms and traditional session management techniques.
Basically, the problem is such:
Sessions are usually stored in RAM. Thus, the session only exists on one web server even if there are lots of web servers. To make sure that the right webserver gets the traffic, the client IP, destination IP, and (sometimes) destination port are hashed together to determine which server to go to. Because the hash is deterministic between requests, this method insures that if a user hits Box A, he will continue to hit Box A, provided these things do not change (that is - source IP and destination IP/port).
The problem with the mega proxies (and lots of other forms of NAT where there are multiple outgoing IPs) is that the source IP does change. Thus, the hashing technique described above fails. Cisco Local Directors amoung others do exactly this.
The solution I've implemented basically keeps the session information in RAM, although it does this through a middle-layer. If I get a session ID from a browser but can not find that session ID in my RAM, I put a querry out to the server farm network and ask, "Who has this?" Whoever has it transfers the session to me (transfer, NOT copy, as I only want one authorative copy).
You have to be careful of concurrancy issues while doing this, but if you are careful, it will work well and be extremely fast for the majority of users, as they remain at one IP for the duration of thier session. But it allows the possibility of a session migrating.
Another option is to use a central "session repository" like a database or special application server. These are almost always going to be bottlenecks, though.
I will say that this is not uncharted territory. The solutions to these kinds of problems are well known. If you are dealing with Fortune 500 companies, make sure your project is funded well enough to bring in some as consultants... This is a fundamental issue to get right, and if you have problems here, I suspect you'll encounter some problems later.
This is incorrect. Proper smartcard implementations zeroize the key of the smartcard after a short number of incorrect PIN entries (a better word then PIN is "password", since it can be a traditional strong password).
The result of this zeroization is that password guessing is not able to work most of the time, if your password isn't one of the first "x" that the attacker guesses. (I set "x" to 5)
Because the card is zeroized, the only way to "reset" your password is to go - with the card - to someone with the authority to reinitialize your card. Once again, with proper implementation (policy), you won't be able to get that stolen card reinitialized without presenting photo ID (really good implementations have a combined smartcard/photo-id card implementation).
Also, smartcards are not vulnerable to sniffing or keystroke monitoring. Even though you could capture the PIN with the monitor (but not sniffer), you still need the card.
Finually, even a program running on the same computer as a logged-in smartcard user can not get the private key off the card. Not even the smartcard user can do that - it is generated on the card and stays on the card (alternatively it is written, but not readable, and it is written from a secure non-networked terminal). Because the private key is needed to answer the cryptographic challenge - which can't be anticipated in advance - the smartcard must be in the attacker's possession. It eliminates almost all network based attacks (the only ones that remain are due to software bugs - not technology bugs).
Thus, a compromise of one component of the smartcard system (either the PIN or the card) is not enough to attack the system. Both systems are gaurded carefully in a well-implemented solution, making it very difficult to gain illicit access. Combined with widespread encryption and digital signatures - with decryption and signing taking place on the card - even a network-based attacker won't find any data he can read. (yes, there are cryptographic attacks, but these are very difficult to do compared to normal computer security attacks)
I love Linux. I use it almost exclusively at home.
But: I would not even consider what you are planning. You are considering computer costs, but not user costs. The costs of running the computing infrastructure (licensing, hardware, maintenance) are only some of the costs involved, and they are the small costs.
The large costs are the cost of retraining 9000+ users. This is something you should not underestimate. Are those users going to be happy when they are running late, but can't figure out how to make Star Office (or whatever else) do what they know how to do in Word? Absolutely not.
Some of the ENTERPRISE level problems with Linux currently:
1) Think about directories. Any enterprise not implementing some sort of enterprise-wide directory needs to fire thier CTO. You need one source of information on all users that is stored in a central place and can be used by all applications. Sadly, MS is much closer to this then Linux right now. (Don't say "LDAP", either, since it is not supported in many applications - like kde/shell/whatever-else login!)
2) Think about remote access. I've not been impressed by Linux's support for VPN. It's much better today then it was 3 or 4 years ago, but it is not done yet. If you use Windows, it comes out of the box (PPTP or, for the more security minded, L2TP). If you don't like either MS option, buy a third party option.
3) Think about exchanging data. Ask your userbase how much data they exchange and with who. You might find that "PowerPoint Clone" isn't good enough. It doesn't matter why it isn't good enough - the fact is that people who exchange documents and require the document's formatting to be exchanged intact need to run the same program as the sender.
4) Think about what your users know already. The less you have to change things, the better from thier standpoint.
5) Think about databases. If you are really that large of a university, you will need some centrally administered databases. Databases which support huge datasets, stored procedures, transactions, foreign keys, etc. You might argue for PostgresSQL, but it won't stand up unless you find some reporting applications and such for the clients. Don't say Oracle, either, since Oracle on Linux is missing many features found in thier NT and Solaris offerings.
6) Think about wierd hardware and integration with legacy machines. Right now, you do have that integration - in some way you can talk to all your machines. Make sure you don't break that. Think about people like EE and Physics, too, who might have some very wierd things hooked up to thier machines.
Good luck - don't make the decision based on what either the Linux or MS lobby says. Instead, figure out where your enterprise needs to be 5 years from now and pick the software that supports the majority of the needs. Sadly, it may be MS software, since it does support directories, remote access, data exchange, existing user knowledge, databases, wierd hardware, and integration with other systems. Linux supports some of these, but does it support all of them?
I haven't even mentioned things like PKI (not certificates, but actual infrastructure - things like automatic certificate renewal), wierd applications, etc, which I'm sure you'll figure out if you do a large scale study of where you want to be tomorrow.
Lots of people have mentioned terminal emulators, which is definately a start.
However, there are several problems:
1) The AS/400 might not have TCP. Thus, you might not be able to telnet to it *EVEN WITH THE PROPER TERMINAL EMULATOR*! Talk to your AS/400 administrator about this and see if you can get TCP set up on the AS/400. Of course, make sure you have a good firewall before you do that.
2) PRINTING. Many shops use Client Access to allow a local workstation printer to be attached to the AS/400. There is no solution for this problem that I know of, although maybe an AS/400 can print to an LPD server (once again, use a firewall!). Talk to your AS/400 admin and ask if people use this feature right now. People will be rightfully pissed if they can't print.
3) No IBM support. I don't know if this will be a problem or not for your environment.
Where is CVS bad? Simple - where you have multiple active branches at one time (think a QA branch, a development branch, and a production branch - you might fix bugs in production, so it is still an active branch).
Try the following with CVS:
- Merge the changes that fixed bug #5212 from branch A to branch B. Don't merge any of the other development that has happened in branch A since then. Make sure to get all the files that were affected.
Simply put, CVS doesn't do this well.
Perforce is the tool I recommend, although CVS is fine if you only have one line of development at a time.
I worked at a coal mine - lots of conductive carbon dust floating around in the air. We lost keyboards, monitors, motherboards, and lots and lots of power supplies.
We always replaced the manufacturer's power supplies with PC Power & Cooling supplies. They use real ball bearings in thier fans (so they last longer), and they tolerate lots of dust. We never had one of these blow up. I can't think of any other brand that we could say the same about.
Try PC Power & Cooling. They have a 3 drive unit that fits in 2 5-1/4" drive bays. As an added bonus, it includes a fan on the front. Granted, there is no backplane, but this lets you mix SCSI, IDE, and whatever else you can fit in there.
I ran VBBS, too, but I don't think you can consider it a "decent" piece of software. I had about 50 patches I would apply to the source code of every version - not to modify the board, but just to make it work correctly. It was very ugly. Things just didn't work right on it.
The vscript idea was very neat, though. I extended the vscript language several times, and found it to be an awesome way of adding "small" add-ons.
--
joel.maslak@p1.f17.n316.z1.fidonet.org
(remember those addresses?)
I did much of the same stuff. I ran a VBBS system (talk about some kludges!) on FidoNet for several years. It included a custom-written mail processor, so that I wouldn't have to run VFido (it took hours to process two or three echos). A piece of mail would pass through about 10 different programs before it ended up in someone's mail box - it was a living, breathing kludge!
I also suggested some changes to the FidoNet nodelist, including a distributed DNS-like system. Alas, no one liked the ideas!
As for the politics, yes, I remember those not too fondly. I had the dubious distinction of having more complaints filed against me than almost all of the rest of FidoNet combined. We had one person in the local network who really had a problem with me!
I don't know if I'm glad I'm out of that network or not. There were some good times, but a lot of ugly times, too.
I must agree! I've been without a real-life live television[1] for the last 3 years, and I don't have any regrets. Sure, when someone says, "Have you seen that new foobar commercial," I have to admit that I have no idea what a foobar is nor did I see the commercial. But, it's much better that way. After all, I've found that the time I've saved has allowed me to say to my friends, "Do you know what it is like to camp in the mountains during winter?" Of course most of them don't. Personally, I'd rather know the what nature is like than knowing that Micky Mouse endorsed FooBars [2]!
As an off-topic statement, losing the TV has done wonders for me. Not only do I get sleep at night now, but I also have times for the stuff that really is important to me, like spending time in - get this - the "real world". This is probably the only reason I wouldn't get a TiVo - I'd be tempted to sit on my butt in front of a TV much too often since I wouldn't have to watch the multitude of programs designed for the "Average Consumer". I'd never bore of the many Star Treks, Simpsons, and King of the Hills.
Maybe I better get a TV antenna, though, since Dvorak seems to think that since radio waves containing commercial programs pass through my residence with the expectation that I'll buy some of their products.
[1] I do have a DVD player and VCR, as well as a friend who gives me a recorded Star Trek the Next Generation episode each week in exchange for me buying him a VCR. Oh, I can't say that. I might get busted for pirating Star Trek! (And, yes, I use the "Commercial Skip" button on my remote to shorten Star Trek to 40 minutes.) I guess I have a Human TiVo.;)
[2] When is someone going to make a candy/energy bar for geeks called the FooBar? Think Geek (hint, hint) could market it on the net... You could make a TV commercial for it that had a geek sitting in front of a computer working in a hex editor, reaching for a now-empty pizza box. Rather than dieing on your TV, he would grab break the glass on the front of a red metal emergency food box and grab this FooBar. If anyone does anything like this, remember me and send me one or two!
It includes maps of the stations that get to make it in.
As a disappointment, there are some dweebs that are tying up the link by sending too frequent of beacons. After all, if you can wait an hour between passes, can't you be happy if only 1 or 2 beacons are heard an hour?
I don't know why people insist on ignoring the RFCs on private network numbers.
If you only have a small network, or a group of small networks, use the 192.168. addresses. This is what the RFC recommends. Yes, I know 10.x.x.x is easier to remember, but it will cause you problems down the road, since everyone thinks they should use it.
Why? You might say, "They are both reserved addresses - why would one have any trouble?" Technically, you are correct. However, the problems come when two private networks connect to each other (you and your friend set up a VPN, your ISP does something like you describe, two companies merge).
To avoid these problems MOST of the time, pick a random number between 0 and 255. Use a net address of 192.168.. Chances are this won't conflict with someone else's network when you merge your networks.
I worked for a couple of years as a technical lead. One thing I did a lot of was review resumes.
If you know that there are only a few people applying for a job, go ahead and send me 2 pages. Otherwise, send me ONE page. Hiring managers are busy. Programmers are, too (hiring managers usually refer resumes to a few programmers). More than one page *WILL NOT GET READ* - it will be skimmed. Do you want someone skimming to not see your Oracle reference for the DBA position? Besides, most people (sorry) don't have more than one page of qualifications. List your skills (the ones that matter for the job), tell me that you've been in the industry using various languages for x years, and tell me about your last two or three jobs. If your talking mostly about your skills, more than three years isn't useful anyhow - except to tell me that you know the art of programming. Say that in one sentence instead of two pages.
If you email a resume, it is NOT an excuse to make it longer. Make sure it is SHORTER than one page, as I might be using a slightly different printer than you. Don't send anything but Word, Plain Text (nicely formatted), or PDF. My preference was PDF, BYMV.
Put a web link on your page. This should be a site completely seperate from your personal homepage. It shouldn't talk about cats, dogs, or what you thought of your last employer. If you have a personal homepage on www.example.com/~bob, and you give a link to "www.example.com/~bob/work", you can bet I'll check both pages. They both better sell yourself.
What do I put on this web page? I put my "LONG" resume there and call it a "work history". I usually put a little "about myself" info there, and some "career goals". This way, if someone is interested, I didn't give them 3 pages to wade through for information - I gave them one with a pointer to get more info.!
On this "work" home page, make sure you pay extra so that you can see the web logs. It is always useful to know if a company is considering you or not. If they are, you'll usually see multiple hits from them on multiple days (more than one person will review resumes). If you see the hits, you know one or two things: One: you barely meet the requirements on your resume, and they are trying to see if you might actually know your stuff. Two: They are VERY interested. Use this to negotiate. You'll usually know what end of the spectrum you are on. (yes, this is similar to the time honored references aproach, where you tell your references to call you the minute they get called by a potential employer).
The Univeristy won't consider these essential services if the University runs the dorm's telephone service (and, thus, makes a cut off of the long distance)...
Outgoing FTP (connecting to an off-site server) causes the FTP server to initiate a connection back to you.
While it is true that many firewalls have logic to allow this, simple packet filters do not and can not - you have to allow anything with a SOURCE port of 20 to connect to ANY high numbered port. But, this argument against packet filters only works if they really are using a packet filter - and not some sort of smart firewall.
As far as a university denying connections, make sure that there is some way to gain exceptions to this policy, just in case there are accademic reasons for doing something down the road. For instance, they could require a proposal signed off by a department head, which indicates the academic value of opening the port and what precautions you are taking against abuse.
Sadly, though, my guess is that there aren't too many accademic reasons for putting a server in your dorm room instead of using a university managed server - other than to try to put up a server which doesn't fall under the normal AUP. Sure, it's a fun project and teaches a lot about administration - but it provides little academic gain that setting up a university-wide-only server would not.
Find out what their reasons for doing this are. Are they trying to reduce a security threat? Or is it really bandwidth? Make sure your argument addresses their - legitimate - concerns.
The person asking this question mentioned that his web logs and the advertiser's web logs didn't match. As someone who has worked in the online advertising industry, I can provide a few pieces of information that may help you understand why they don't match.
First, multiple visits from the same IP or user will be aggregated into less impressions and click-throughs.
Second, one person seeing the same banner 5 times might only count as one impression.
Third, search engines and robots don't get counted.
What you will want to do is to verify that any ad network you use has a legitimate business model. In general, if someone gave them millions of $$$ to run their business, they probably won't screw you, for public opinion is everything to an ad network. Once word gets around that you shortchange sites, you'll quickly lose any hope of becoming profitable - and the ad networks know this.
In my experience, they try their best to accurately pay you what you deserve, without screwing themselves, either.
I've worked for several email marketing companies. Some were very good, requiring opt-in on everything. Others weren't as good, although anyone from any of these companies would tell you, "we don't spam." This is a problem in the industry, and it must be addressed for the spam to stop.
I've seen the future, I've worked there. I don't see spam going away, no matter how much it costs or annoys us, nor do I see addresses not being sold and used for "direct mail".
I hear lots of talk about requiring "opt in", but can the US really do that? I don't opt in when a political canidate comes to my door to sell me on his campaign - and I shouldn't, for that's what free speech means. Where in the constitution does the federal government get that power (and don't say "regulating interstate commerce!"). Why would a government that allows sale of postal addresses (a physical safety threat!) but not allow sale of "virtual" addresses?
One ironic part of the internet is that every user thinks that they should have ultimite protection of free speech, and that the Internet should never be censored. We should be able to view our porn without risk of being jailed. Yet, at the same time, while porn is considered protected by internet activists (although, it could be argued, forms of pornography harm society) - these same activists want to ban a form of speech that they happen to not like - spam.
Oh, that's right, spam costs the sender money. You see, in the US, where we pay $19.95 for unlimited internet access, we consider a modem downloading a few thousands ones to be "expensive". Face it: it's not. True, some spammers have abused other's resources, but there will be many who don't. (Spammers may even pay a fee to the ISP affected by the spam, the same way junk mailers pay the post office - but I bet people will still hate the spam just as much) You still pay for postal junk mail, too. You might even pay more for postal mail than for spam! My time is fairly valuable, as I have a limited amount of it in my lifetime. I venture to say it takes slightly more time to throw away a junk postal mail than to delete a spam email (especially if the postal mail is a credit card application, and I'd rather someone else didn't use that information). Yet, my time is considered less valuble than a fraction of a cent that it costs a spam to sit on some server.
Oh, and for the record: I hate spam. But, I realize that I live in a free society and sometimes people do things that I really don't like. True freedom is only possible when someone can anger another without fear of the law or their safety.
I'm the initial developer of an open source project that is just a couple months old. Here's my suggestions, as someone who is also new to this.
1) Make sure you like the project. Make sure you will use the project! If it doesn't fill one of your own needs, you won't stick with it. If it fulfills one of your own needs, you'll probably be happy with it even when it is small and almost featureless.
2) Announce it to the world! Put it in mailing lists and newsgroups that deal with your subject. Let them know what it does, and what it's limitations are. Give screen shots. Create two mailing lists: one for anouncements, and one for hackers.
3) To capture users and developers, implement a few of their pet features. People want to be involved in a project where the developers are responsive.
I've done #1, #2, #3 and have had a lot more success than I expected. My project, a ham radio APRS display built arount the Palm has actually attracted significant interest. I was more surprised than anyone! It was initially only designed to meet a small need for myself - a mobile APRS display. However, by open sourcing it and putting two features high on the list (a serial port spider another ham designed and implementing the BEACONNet protocol), I was able to get some additional interest in this piece of software.
Right now, I have several developers, lots of potential users, and a HTML page designer in response to my request on the mailing lists for help.
But, the key was that this project solved a need I had and it is something that I enjoy working on. And, I had to do a lot of work to get it to the point where I could communicate what it was to potential developers. Starting a successful project isn't easy.
In programming, there's a long tradition of using someone's login name as their nickname.
For instance, who doesn't know who RMS is? I've been called JCM and jmaslak verbally more than a few times (from my login names on previous computer installations). These names become attached to the real people because the login name, rather than full name, usually appears in source code. If I read your code, I naturally begin to feel that I know the person who typed his login name. But, I might not know his "real" name!
A new trend, with the networked PC, may be to call people by their computer's hostname. Anyone who has used Perforce will understand this, as the Perforce client defaults to the computer's name when installed. Thus, checkins from a workstation appear with the workstation's name, not the user's name.
I don't know why the poster limited himself to just C and Java. Perhaps it was due to the learning curve, in which case he probably should stick with C or Java (probably C since it doesn't seem that there is a good Java for his target platform).
However, if he is willing to learn a language, he should consider something like Perl. I know that Perl handles this problem in a fairly elegant way compared to the dlopen interface.
He might also consider building a system around some sort of multi-process communications system, such as COBRA (or even a simple blackboard communication system).
> Um...why do you say they're on the same segment? Don't you know how netmasks work?
I *DO* know how subnets work, and, most likely, these *ARE* subnetted. But, that's beside the point.
You can't distribute a BGP route with a mask of more then 24 bits, due to restrictions most providers have on route propagation. You can try it, but it will fall into the bit bucket on some backbones.
The reasons the backbones do this is to limit the number of routes on the Internet.
As a result, from a backbone provider's point of view, the entire class C (at a MINIMUM! Can anyone post exactly what MS's BGP routes look like?) is pointing at a signle point of enterence into the network. Thus, while MS definately has redundant backbone connections, your traceroutes will always follow the same path for ANY address in this class C -- until you get into MS's network -- even if the subnetted.
I hope this makes sense. It's complicated, but the simple way of explaining it is: There is ONLY ONE ROUTE INTO THIS CLASS C. Thus, it goes into a single geographical location, although it may go back out through MS's network to others.
Slashdot Mirror
A load balancer does not give redundancy. With a load balancer, if a server dies, NEW connections are sent to a different server instead, but the existing connections to the down server all are closed - an external non-OS integrated solution like load balancing does not give transparent failover on TCP connections. It works for HTTP because browsers are used to connections suddenly dieing and will simply retry. But, if the client isn't smart enough to reconnect, it won't work.
The way to do this is to build a custom TCP stack and integrate it tightly into your app. A lot of work and hard to get right.
I would ask, "Do we REALLY" need this when our application already has to handle things like network failures? You might, though - I don't know what your application is.
Also, don't forget to use redundant routers, redundant firewalls, etc. If you use NAT, that imposes one more problem - transparently moving the connection table between the failed firewall and the working one.
1) Use some sort of encryption-related technology, like MACs (see my other post)
2) Use some sort of phased array receiving antenna. These can select what direction to listen to a request from. That means that someone would have be in your geographic area or have an EXTREMELY strong antenna (much stronger then yours) to do any sort of DOS or even send legitimate commands.
I do PKI for a living. Actually, in this case, it might not be the right choice.
Do you really mean PKI or simply Public Key Encryption? Do you actually picture a root certificate authority, subordinate certificate authorities, directories, certificate revocation lists, and authority revocation lists being used to secure a satellite's command & control?
PKI is a great choice when you have lots of parties that need to randomly communicate with each other. It provides a great key distribution. However, PKI seems like overkill when one (or, at most, two) ground stations will be talking to a satelite. In this case, distributing a shared secret really isn't that difficult - probably much easier then building a PKI network and keeping it secure! Of course it does depend on if you trust your internal computer systems to keep the key private. If you don't, then PKI might solve some of your problems.
I would suggest a very lightweight approach. Privacy of data is not required for this application, IMHO. Maybe I'm wrong, in which case, you should investigate other options. This sounds like a good case for a MAC (Message Authentication Code). You don't even need to use encryption - just hashing - to do this.
Basically, each end has a shared secret, "S".
You have a packet containing data, "D".
Each packet has a timestamp (to prevent replay attacks) "T".
All packets consist of: D+T+MD5(D+T+S)
Of course, you can use some sort of hash besides MD5. You can also program the satelite with a few thousand secrets, which expire every so often - if you give it 100 years of secrets at launch, you should be fine.
The satelite receives this packet, does the MD5 of D+T+S, and compares the numbers. It doesn't let you use a packet with an old T (T should be very close to the current time and T should be greater then the most recent T).
This code has the benefit of taking very little memory space compared to a PKI solution. It's also much easier on the uplink/downlink channels.
The most important thing to remember, though, is that this shared secret has to be kept secret. It should not be used by your normal programmers to write control software. Instead, it should be an external module that runs on a secure box (I.E. no remote administration capabilities, only allows connections via a secure interface, and adds on the MAC as the messages pass through it). If you can afford a satellite, you can afford one secure server! I would definately investigate commercial encryption devices which add on a MAC using a shared secret - at least on the ground-station end. They of course may function differently then the method I described above, but the basics remain the same.
Of course all of this has been solved before. ATMs and banks have long needed to authenticate the other end. (ATMs, BTW, do not use public key cryptography, but simply a split key pair - that is, a random string of numbers is one part of the pair and that string XORed with the real key is the other pair - each part is given to a different person who keys it into the ATM seperately from the other person - you might also incorporate this type of system). Since this has been solved before, I recommend that you hire some sort of encryption expert to help you (you are NOT looking for a computer security person - chances are you are not running a default install of W2K on your satellite!).
As for IP, I would think that you would want to ensure there was no way for someone outside the control room to use your equipment to send command and control messages to your satellites! At the very least, this means that the control room should probably have an air-gap between it and the rest of your network. Sure, a little inconvienient, but how much command and control data do you really have to share with people outside that room? Not much most likely - certainly not too much to retype.
Almost every story here seems to be, "Waaaaaa! I can't get foo for free!!! Waaaaa!"
First, there is griping about the "broadband monopoly". Apparently, for $25/month, we are entitled to buy broadband when our usage will cost the company more then they will make. Strange, I know, but people here just don't get it - companies exist to make money. Apparently, if I'm the only person making a particular product, I'm obligated by "monopoly" to sell every version of it imaginable for the price that Slashdot thinks I should.
As for this software piracy, the real issue is that people don't want to pay for software. It isn't anymore complicated then that. They have very complicated justifications, but they don't want to pay for thier software. Fine, don't. But don't use it, either.
I think the biggest thing that could be done for open source software would be an enforcement of piracy law. Think about it - how many people would keep using Word at home if they had to pay for it? Don't you think that it might help some of the OSS word processors get market share? But, no, we're whining about how we should be able to use Windows and Word for free. Even the Slashdot community, who is supposed to be pro-OSS, seems to think that commercial software is better then the alternatives (at least for some things). If we don't believe what we preach (that OSS is best), then how can we expect others to?
After all, doesn't the music theft crowd believe that piracy increases the sales and populatiry of music? Why, then, would we pirate software on the moral grounds that the company doesn't deserve our money? Our piracy may contribute to the company's bottom line.
What kind of problems are you having? Because you mentioned large organizations, I'm assuming you are talking about problems with large-volume web server farms and traditional session management techniques.
Basically, the problem is such:
Sessions are usually stored in RAM. Thus, the session only exists on one web server even if there are lots of web servers. To make sure that the right webserver gets the traffic, the client IP, destination IP, and (sometimes) destination port are hashed together to determine which server to go to. Because the hash is deterministic between requests, this method insures that if a user hits Box A, he will continue to hit Box A, provided these things do not change (that is - source IP and destination IP/port).
The problem with the mega proxies (and lots of other forms of NAT where there are multiple outgoing IPs) is that the source IP does change. Thus, the hashing technique described above fails. Cisco Local Directors amoung others do exactly this.
The solution I've implemented basically keeps the session information in RAM, although it does this through a middle-layer. If I get a session ID from a browser but can not find that session ID in my RAM, I put a querry out to the server farm network and ask, "Who has this?" Whoever has it transfers the session to me (transfer, NOT copy, as I only want one authorative copy).
You have to be careful of concurrancy issues while doing this, but if you are careful, it will work well and be extremely fast for the majority of users, as they remain at one IP for the duration of thier session. But it allows the possibility of a session migrating.
Another option is to use a central "session repository" like a database or special application server. These are almost always going to be bottlenecks, though.
I will say that this is not uncharted territory. The solutions to these kinds of problems are well known. If you are dealing with Fortune 500 companies, make sure your project is funded well enough to bring in some as consultants... This is a fundamental issue to get right, and if you have problems here, I suspect you'll encounter some problems later.
This is incorrect. Proper smartcard implementations zeroize the key of the smartcard after a short number of incorrect PIN entries (a better word then PIN is "password", since it can be a traditional strong password).
The result of this zeroization is that password guessing is not able to work most of the time, if your password isn't one of the first "x" that the attacker guesses. (I set "x" to 5)
Because the card is zeroized, the only way to "reset" your password is to go - with the card - to someone with the authority to reinitialize your card. Once again, with proper implementation (policy), you won't be able to get that stolen card reinitialized without presenting photo ID (really good implementations have a combined smartcard/photo-id card implementation).
Also, smartcards are not vulnerable to sniffing or keystroke monitoring. Even though you could capture the PIN with the monitor (but not sniffer), you still need the card.
Finually, even a program running on the same computer as a logged-in smartcard user can not get the private key off the card. Not even the smartcard user can do that - it is generated on the card and stays on the card (alternatively it is written, but not readable, and it is written from a secure non-networked terminal). Because the private key is needed to answer the cryptographic challenge - which can't be anticipated in advance - the smartcard must be in the attacker's possession. It eliminates almost all network based attacks (the only ones that remain are due to software bugs - not technology bugs).
Thus, a compromise of one component of the smartcard system (either the PIN or the card) is not enough to attack the system. Both systems are gaurded carefully in a well-implemented solution, making it very difficult to gain illicit access. Combined with widespread encryption and digital signatures - with decryption and signing taking place on the card - even a network-based attacker won't find any data he can read. (yes, there are cryptographic attacks, but these are very difficult to do compared to normal computer security attacks)
I love Linux. I use it almost exclusively at home.
But: I would not even consider what you are planning. You are considering computer costs, but not user costs. The costs of running the computing infrastructure (licensing, hardware, maintenance) are only some of the costs involved, and they are the small costs.
The large costs are the cost of retraining 9000+ users. This is something you should not underestimate. Are those users going to be happy when they are running late, but can't figure out how to make Star Office (or whatever else) do what they know how to do in Word? Absolutely not.
Some of the ENTERPRISE level problems with Linux currently:
1) Think about directories. Any enterprise not implementing some sort of enterprise-wide directory needs to fire thier CTO. You need one source of information on all users that is stored in a central place and can be used by all applications. Sadly, MS is much closer to this then Linux right now. (Don't say "LDAP", either, since it is not supported in many applications - like kde/shell/whatever-else login!)
2) Think about remote access. I've not been impressed by Linux's support for VPN. It's much better today then it was 3 or 4 years ago, but it is not done yet. If you use Windows, it comes out of the box (PPTP or, for the more security minded, L2TP). If you don't like either MS option, buy a third party option.
3) Think about exchanging data. Ask your userbase how much data they exchange and with who. You might find that "PowerPoint Clone" isn't good enough. It doesn't matter why it isn't good enough - the fact is that people who exchange documents and require the document's formatting to be exchanged intact need to run the same program as the sender.
4) Think about what your users know already. The less you have to change things, the better from thier standpoint.
5) Think about databases. If you are really that large of a university, you will need some centrally administered databases. Databases which support huge datasets, stored procedures, transactions, foreign keys, etc. You might argue for PostgresSQL, but it won't stand up unless you find some reporting applications and such for the clients. Don't say Oracle, either, since Oracle on Linux is missing many features found in thier NT and Solaris offerings.
6) Think about wierd hardware and integration with legacy machines. Right now, you do have that integration - in some way you can talk to all your machines. Make sure you don't break that. Think about people like EE and Physics, too, who might have some very wierd things hooked up to thier machines.
Good luck - don't make the decision based on what either the Linux or MS lobby says. Instead, figure out where your enterprise needs to be 5 years from now and pick the software that supports the majority of the needs. Sadly, it may be MS software, since it does support directories, remote access, data exchange, existing user knowledge, databases, wierd hardware, and integration with other systems. Linux supports some of these, but does it support all of them?
I haven't even mentioned things like PKI (not certificates, but actual infrastructure - things like automatic certificate renewal), wierd applications, etc, which I'm sure you'll figure out if you do a large scale study of where you want to be tomorrow.
Lots of people have mentioned terminal emulators, which is definately a start.
However, there are several problems:
1) The AS/400 might not have TCP. Thus, you might not be able to telnet to it *EVEN WITH THE PROPER TERMINAL EMULATOR*! Talk to your AS/400 administrator about this and see if you can get TCP set up on the AS/400. Of course, make sure you have a good firewall before you do that.
2) PRINTING. Many shops use Client Access to allow a local workstation printer to be attached to the AS/400. There is no solution for this problem that I know of, although maybe an AS/400 can print to an LPD server (once again, use a firewall!). Talk to your AS/400 admin and ask if people use this feature right now. People will be rightfully pissed if they can't print.
3) No IBM support. I don't know if this will be a problem or not for your environment.
Where is CVS bad? Simple - where you have multiple active branches at one time (think a QA branch, a development branch, and a production branch - you might fix bugs in production, so it is still an active branch).
Try the following with CVS:
- Merge the changes that fixed bug #5212 from branch A to branch B. Don't merge any of the other development that has happened in branch A since then. Make sure to get all the files that were affected.
Simply put, CVS doesn't do this well.
Perforce is the tool I recommend, although CVS is fine if you only have one line of development at a time.
I worked at a coal mine - lots of conductive carbon dust floating around in the air. We lost keyboards, monitors, motherboards, and lots and lots of power supplies.
We always replaced the manufacturer's power supplies with PC Power & Cooling supplies. They use real ball bearings in thier fans (so they last longer), and they tolerate lots of dust. We never had one of these blow up. I can't think of any other brand that we could say the same about.
Try PC Power & Cooling. They have a 3 drive unit that fits in 2 5-1/4" drive bays. As an added bonus, it includes a fan on the front. Granted, there is no backplane, but this lets you mix SCSI, IDE, and whatever else you can fit in there.
I ran VBBS, too, but I don't think you can consider it a "decent" piece of software. I had about 50 patches I would apply to the source code of every version - not to modify the board, but just to make it work correctly. It was very ugly. Things just didn't work right on it.
The vscript idea was very neat, though. I extended the vscript language several times, and found it to be an awesome way of adding "small" add-ons.
--
joel.maslak@p1.f17.n316.z1.fidonet.org
(remember those addresses?)
I did much of the same stuff. I ran a VBBS system (talk about some kludges!) on FidoNet for several years. It included a custom-written mail processor, so that I wouldn't have to run VFido (it took hours to process two or three echos). A piece of mail would pass through about 10 different programs before it ended up in someone's mail box - it was a living, breathing kludge!
I also suggested some changes to the FidoNet nodelist, including a distributed DNS-like system. Alas, no one liked the ideas!
As for the politics, yes, I remember those not too fondly. I had the dubious distinction of having more complaints filed against me than almost all of the rest of FidoNet combined. We had one person in the local network who really had a problem with me!
I don't know if I'm glad I'm out of that network or not. There were some good times, but a lot of ugly times, too.
I must agree! I've been without a real-life live television[1] for the last 3 years, and I don't have any regrets. Sure, when someone says, "Have you seen that new foobar commercial," I have to admit that I have no idea what a foobar is nor did I see the commercial. But, it's much better that way. After all, I've found that the time I've saved has allowed me to say to my friends, "Do you know what it is like to camp in the mountains during winter?" Of course most of them don't. Personally, I'd rather know the what nature is like than knowing that Micky Mouse endorsed FooBars [2]!
;)
As an off-topic statement, losing the TV has done wonders for me. Not only do I get sleep at night now, but I also have times for the stuff that really is important to me, like spending time in - get this - the "real world". This is probably the only reason I wouldn't get a TiVo - I'd be tempted to sit on my butt in front of a TV much too often since I wouldn't have to watch the multitude of programs designed for the "Average Consumer". I'd never bore of the many Star Treks, Simpsons, and King of the Hills.
Maybe I better get a TV antenna, though, since Dvorak seems to think that since radio waves containing commercial programs pass through my residence with the expectation that I'll buy some of their products.
[1] I do have a DVD player and VCR, as well as a friend who gives me a recorded Star Trek the Next Generation episode each week in exchange for me buying him a VCR. Oh, I can't say that. I might get busted for pirating Star Trek! (And, yes, I use the "Commercial Skip" button on my remote to shorten Star Trek to 40 minutes.) I guess I have a Human TiVo.
[2] When is someone going to make a candy/energy bar for geeks called the FooBar? Think Geek (hint, hint) could market it on the net... You could make a TV commercial for it that had a geek sitting in front of a computer working in a hex editor, reaching for a now-empty pizza box. Rather than dieing on your TV, he would grab break the glass on the front of a red metal emergency food box and grab this FooBar. If anyone does anything like this, remember me and send me one or two!
http://www.ariss.net/
It includes maps of the stations that get to make it in.
As a disappointment, there are some dweebs that are tying up the link by sending too frequent of beacons. After all, if you can wait an hour between passes, can't you be happy if only 1 or 2 beacons are heard an hour?
I don't know why people insist on ignoring the RFCs on private network numbers.
If you only have a small network, or a group of small networks, use the 192.168. addresses. This is what the RFC recommends. Yes, I know 10.x.x.x is easier to remember, but it will cause you problems down the road, since everyone thinks they should use it.
Why? You might say, "They are both reserved addresses - why would one have any trouble?" Technically, you are correct. However, the problems come when two private networks connect to each other (you and your friend set up a VPN, your ISP does something like you describe, two companies merge).
To avoid these problems MOST of the time, pick a random number between 0 and 255. Use a net address of 192.168.. Chances are this won't conflict with someone else's network when you merge your networks.
I worked for a couple of years as a technical lead. One thing I did a lot of was review resumes.
If you know that there are only a few people applying for a job, go ahead and send me 2 pages. Otherwise, send me ONE page. Hiring managers are busy. Programmers are, too (hiring managers usually refer resumes to a few programmers). More than one page *WILL NOT GET READ* - it will be skimmed. Do you want someone skimming to not see your Oracle reference for the DBA position? Besides, most people (sorry) don't have more than one page of qualifications. List your skills (the ones that matter for the job), tell me that you've been in the industry using various languages for x years, and tell me about your last two or three jobs. If your talking mostly about your skills, more than three years isn't useful anyhow - except to tell me that you know the art of programming. Say that in one sentence instead of two pages.
If you email a resume, it is NOT an excuse to make it longer. Make sure it is SHORTER than one page, as I might be using a slightly different printer than you. Don't send anything but Word, Plain Text (nicely formatted), or PDF. My preference was PDF, BYMV.
Put a web link on your page. This should be a site completely seperate from your personal homepage. It shouldn't talk about cats, dogs, or what you thought of your last employer. If you have a personal homepage on www.example.com/~bob, and you give a link to "www.example.com/~bob/work", you can bet I'll check both pages. They both better sell yourself.
What do I put on this web page? I put my "LONG" resume there and call it a "work history". I usually put a little "about myself" info there, and some "career goals". This way, if someone is interested, I didn't give them 3 pages to wade through for information - I gave them one with a pointer to get more info.!
On this "work" home page, make sure you pay extra so that you can see the web logs. It is always useful to know if a company is considering you or not. If they are, you'll usually see multiple hits from them on multiple days (more than one person will review resumes). If you see the hits, you know one or two things: One: you barely meet the requirements on your resume, and they are trying to see if you might actually know your stuff. Two: They are VERY interested. Use this to negotiate. You'll usually know what end of the spectrum you are on. (yes, this is similar to the time honored references aproach, where you tell your references to call you the minute they get called by a potential employer).
Good luck!
The Univeristy won't consider these essential services if the University runs the dorm's telephone service (and, thus, makes a cut off of the long distance)...
Outgoing FTP (connecting to an off-site server) causes the FTP server to initiate a connection back to you.
While it is true that many firewalls have logic to allow this, simple packet filters do not and can not - you have to allow anything with a SOURCE port of 20 to connect to ANY high numbered port. But, this argument against packet filters only works if they really are using a packet filter - and not some sort of smart firewall.
As far as a university denying connections, make sure that there is some way to gain exceptions to this policy, just in case there are accademic reasons for doing something down the road. For instance, they could require a proposal signed off by a department head, which indicates the academic value of opening the port and what precautions you are taking against abuse.
Sadly, though, my guess is that there aren't too many accademic reasons for putting a server in your dorm room instead of using a university managed server - other than to try to put up a server which doesn't fall under the normal AUP. Sure, it's a fun project and teaches a lot about administration - but it provides little academic gain that setting up a university-wide-only server would not.
Find out what their reasons for doing this are. Are they trying to reduce a security threat? Or is it really bandwidth? Make sure your argument addresses their - legitimate - concerns.
The person asking this question mentioned that his web logs and the advertiser's web logs didn't match. As someone who has worked in the online advertising industry, I can provide a few pieces of information that may help you understand why they don't match.
First, multiple visits from the same IP or user will be aggregated into less impressions and click-throughs.
Second, one person seeing the same banner 5 times might only count as one impression.
Third, search engines and robots don't get counted.
What you will want to do is to verify that any ad network you use has a legitimate business model. In general, if someone gave them millions of $$$ to run their business, they probably won't screw you, for public opinion is everything to an ad network. Once word gets around that you shortchange sites, you'll quickly lose any hope of becoming profitable - and the ad networks know this.
In my experience, they try their best to accurately pay you what you deserve, without screwing themselves, either.
I've worked for several email marketing companies. Some were very good, requiring opt-in on everything. Others weren't as good, although anyone from any of these companies would tell you, "we don't spam." This is a problem in the industry, and it must be addressed for the spam to stop.
I've seen the future, I've worked there. I don't see spam going away, no matter how much it costs or annoys us, nor do I see addresses not being sold and used for "direct mail".
I hear lots of talk about requiring "opt in", but can the US really do that? I don't opt in when a political canidate comes to my door to sell me on his campaign - and I shouldn't, for that's what free speech means. Where in the constitution does the federal government get that power (and don't say "regulating interstate commerce!"). Why would a government that allows sale of postal addresses (a physical safety threat!) but not allow sale of "virtual" addresses?
One ironic part of the internet is that every user thinks that they should have ultimite protection of free speech, and that the Internet should never be censored. We should be able to view our porn without risk of being jailed. Yet, at the same time, while porn is considered protected by internet activists (although, it could be argued, forms of pornography harm society) - these same activists want to ban a form of speech that they happen to not like - spam.
Oh, that's right, spam costs the sender money. You see, in the US, where we pay $19.95 for unlimited internet access, we consider a modem downloading a few thousands ones to be "expensive". Face it: it's not. True, some spammers have abused other's resources, but there will be many who don't. (Spammers may even pay a fee to the ISP affected by the spam, the same way junk mailers pay the post office - but I bet people will still hate the spam just as much) You still pay for postal junk mail, too. You might even pay more for postal mail than for spam! My time is fairly valuable, as I have a limited amount of it in my lifetime. I venture to say it takes slightly more time to throw away a junk postal mail than to delete a spam email (especially if the postal mail is a credit card application, and I'd rather someone else didn't use that information). Yet, my time is considered less valuble than a fraction of a cent that it costs a spam to sit on some server.
Oh, and for the record: I hate spam. But, I realize that I live in a free society and sometimes people do things that I really don't like. True freedom is only possible when someone can anger another without fear of the law or their safety.
I'm the initial developer of an open source project that is just a couple months old. Here's my suggestions, as someone who is also new to this.
1) Make sure you like the project. Make sure you will use the project! If it doesn't fill one of your own needs, you won't stick with it. If it fulfills one of your own needs, you'll probably be happy with it even when it is small and almost featureless.
2) Announce it to the world! Put it in mailing lists and newsgroups that deal with your subject. Let them know what it does, and what it's limitations are. Give screen shots. Create two mailing lists: one for anouncements, and one for hackers.
3) To capture users and developers, implement a few of their pet features. People want to be involved in a project where the developers are responsive.
I've done #1, #2, #3 and have had a lot more success than I expected. My project, a ham radio APRS display built arount the Palm has actually attracted significant interest. I was more surprised than anyone! It was initially only designed to meet a small need for myself - a mobile APRS display. However, by open sourcing it and putting two features high on the list (a serial port spider another ham designed and implementing the BEACONNet protocol), I was able to get some additional interest in this piece of software.
Right now, I have several developers, lots of potential users, and a HTML page designer in response to my request on the mailing lists for help.
But, the key was that this project solved a need I had and it is something that I enjoy working on. And, I had to do a lot of work to get it to the point where I could communicate what it was to potential developers. Starting a successful project isn't easy.
How quickly we forget our own history!
In programming, there's a long tradition of using someone's login name as their nickname.
For instance, who doesn't know who RMS is? I've been called JCM and jmaslak verbally more than a few times (from my login names on previous computer installations). These names become attached to the real people because the login name, rather than full name, usually appears in source code. If I read your code, I naturally begin to feel that I know the person who typed his login name. But, I might not know his "real" name!
A new trend, with the networked PC, may be to call people by their computer's hostname. Anyone who has used Perforce will understand this, as the Perforce client defaults to the computer's name when installed. Thus, checkins from a workstation appear with the workstation's name, not the user's name.
I don't know why the poster limited himself to just C and Java. Perhaps it was due to the learning curve, in which case he probably should stick with C or Java (probably C since it doesn't seem that there is a good Java for his target platform).
However, if he is willing to learn a language, he should consider something like Perl. I know that Perl handles this problem in a fairly elegant way compared to the dlopen interface.
He might also consider building a system around some sort of multi-process communications system, such as COBRA (or even a simple blackboard communication system).
> Um...why do you say they're on the same segment? Don't you know how netmasks work?
I *DO* know how subnets work, and, most likely, these *ARE* subnetted. But, that's beside the point.
You can't distribute a BGP route with a mask of more then 24 bits, due to restrictions most providers have on route propagation. You can try it, but it will fall into the bit bucket on some backbones.
The reasons the backbones do this is to limit the number of routes on the Internet.
As a result, from a backbone provider's point of view, the entire class C (at a MINIMUM! Can anyone post exactly what MS's BGP routes look like?) is pointing at a signle point of enterence into the network. Thus, while MS definately has redundant backbone connections, your traceroutes will always follow the same path for ANY address in this class C -- until you get into MS's network -- even if the subnetted.
I hope this makes sense. It's complicated, but the simple way of explaining it is: There is ONLY ONE ROUTE INTO THIS CLASS C. Thus, it goes into a single geographical location, although it may go back out through MS's network to others.
Thus: there is a single point of failure, period.