Softpanorama
(slightly skeptical)
Open Source Software Educational Society
May the source be with you, but remember the KISS principle ;-)
Softpanorama Search
|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
Softpanorama Search
|
Network architecture is very important and affect reliability. Gartner estimated the hourly cost of network downtime for large corporations was $42,000, with a typical business experiencing an average of 87 hours of downtime a year, resulting in total losses exceeding $3.6 mln. This is probably an exaggerated figure as most downtime affect local branches and central services usually run extremely reliably.
Analysts and vendors often tend to produce exaggerated figures for both the number of hours and the cost of network downtime. That also means that managed service providers often are charging companies too much as they does not have significantly higher reliability. Most of networking downtime hype is actually a hidden advertisement of expensive network monitoring solutions. For example:
Network downtime is costing US firms hundreds of millions of dollars in lost productivity, industry analysts warned today.
According to a study from Infonetics Research, firms operating in the financial and manufacturing sectors suffer the biggest financial losses as a result of network outages.
"The finance and manufacturing verticals are bleeding the most," said Jeff Wilson, principal analyst at Infonetics Research, and author of the study.
"The average financial institution experiences 1,180 hours of downtime per year, costing 16 per cent of annual revenue, or $222m. Manufacturers are losing an average of nine per cent of their annual revenue."
Those figures are completely out of line with my personal experience.
Note: Due to the volume of material all information about Solaris IP configuration is now moved to network configuration page.
|
|||||||
Nicholas Carr's provocative HBR article published five years ago and subsequent books suffer from the lack of understanding of IT history, electrical transmission networks (which he uses as close historical analogy) and "in the cloud" software service provider model (SaaS). He cherry-picks historical facts to fit his needs instead of trying to describe real history of development of each of those three technologies. To be more correct Carr tortures facts to get them to fit his fantasy. The central idea of the article "IT does not matter" is simply a fallacy. At best Carr managed to ask a couple of interesting questions, but provided inferior and misleading answers. While Carr is definitely a gifted writer, ignorance of technology about which he is writing leads him to absurd conclusions which due to his lucid writing style looks quite plausible for non-specialists and as such influence public opinion about IT. Still as a writer Carr comes across as a guy who can write engagingly about a variety of topics including those about which he knows almost nothing. Here lies the danger as only specialists can sense that that "Something Is Deeply Amiss" while ordinary readers tend to believe his aura of credibility emanating from the "former editor of HBR" title.
Unfortunately the charge of irrelevance of IT made by Carr was perfectly in sync with the higher management desire to accelerate outsourcing and Carr's 2003 HBR paper served as a kind of "IT outsourcing manifesto". And the fact that many people were sitting between chairs as for the value of IT outsourcing partially explains why his initial HBR article, as weak and detached from reality as it was, generated less effective rebuttals then it should. This paper is an attempt to provide a more coherent analysis of the main components of Carr's fallacious vision five years after the event.
If one looks closer at what Carr propose, it is evident that this is a pretty reactionary and defeatist framework which I would call "IT obscurantism" and which is not that different from "creativism". Like with the latter, his justifications are extremely weak and consist of one hand of usage of fuzzy facts and questionable analogies, on the other putting forward radical, absurd recommendations ("Spend less", "Follow, don't lead", "Focus on vulnerabilities, not opportunities" and "move to utility-based 'in the cloud' computing") which can hurt anybody who trusts them or, worse, tries blindly adopt them. The irony of Carr's position is that for the last five year since the publication of his HBR article local datacenters actually flourished and until 2008 had shown no signs of impeding demise. In 2008 credit crush his data centers but they are just collateral damage of financial storm. From 2003 to 2008 Data Centers experienced just another technological reorganization which increased role of Intel computers in the datacenter (including appearance of blades, as alternatives to small to midrange servers and laptops as the alternative to desktop), virtualization, wireless technologies and distributed computing. Moreover there was some trend to the consolidation of datacenters within the large companies.
The paper contains critique of key aspects of Carr's utopia including but not limited to such typical for Carr's writings problems as "Frivolous treatment of IT history", "Limited understanding of enterprise IT", " "Idealization of 'in the cloud' computing model". and "Compete absence of discussion of competing technologies". The author argues that the level of hype about "utility computing" makes prudent treating all promoters of this interesting new technology, especially those who severely lack technical depth, with extreme skepticism. Junk science is and always was based on cherry-picked evidence which has carefully been selected or edited to support a pre-selected, absurd "truth". The article claims that Carr's doom-and-gloom predictions about IT and datacenters are based on cherry-picked evidence and while future is unpredictable by definition, the total switch to the Internet based remote "in the cloud" computing probably will never materialize. Private and hybrid models are definitely more viable. There is no free lunch and moving computation to the cloud increases the load on the remote servers as well as drastically increases security requirements. Both factors increases costs. Achieving the same reliability for the cloud computing as in local solution is another problem. Outages of large datacenter are usually more severe and more difficult to recover then outages of small local datacenter. The information flow about outage has severe restrictions that additionally hurt the clients.
20-07-2009Twitter lost its data through a hack on Google Docs. Learn from this to be very careful how much trust you place on cloud apps and Web 2.0, says Eric Lundquist
Here's the background. A hacker apparently was able to access the Google account of a Twitter employee. Twitter uses Google Docs as a method to create and share information. The hacker apparently got at the docs and sent them to TechCrunch, which decided to publish much of the information.
The entire event - not the first time Twitter has been hacked into through cloud apps - sent the Web world into a frenzy. How smart was Twitter to rely on Google applications? How can Google build up business-to-business trust when one hack opens the gates on corporate secrets? Were TechCrunch journalists right to publish stolen documents? Whatever happened to journalists using documents as a starting point for a story rather than the end point story in itself?
Alongside all this, what are the serious lessons that business execs and information technology professionals can learn from the Twitter/TechCrunch episode? Here are my suggestions:
1. Don't confuse the cloud with secure, locked-down environments.
Cloud computing is all the rage. It makes it easy to scale up applications, design around flexible demand and make content widely accessible [in the UK, the Tory party is proposing more use of it by Government, and the Labour Government has appointed a Tsar of Twitter - Editor]. But the same attributes that make the cloud easy for everyone to access makes it, well, easy for everyone to access.2. Cloud computing requires more, not less, stringent security procedures.>br /> In your own network would you defend your most vital corporate information with only a username and user-created password? I don't think so. Recent surveys have found that Web 2.0 users are slack on security.
3. Putting security procedures in place after a hack is dumb.
Security should be a tiered approach. Non-vital information requires less security than, say, your company's five-year plan, financials or salaries. If you don't think about this stuff in advance you will pay for it when it appears on the evening news.4. Don't rely on the good will of others to build your security.
Take the initiative. I like the ease and access of Google applications, but I would never include those capabilities in a corporate security framework without a lengthy discussion about rights, procedures and responsibilities. I'd also think about having a white hat hacker take a look at what I was planning.5. The older IT generation has something to teach the youngsters.
The world of business 2.0 is cool, exciting... and full of holes. Those grey haired guys in the server room grew up with procedures that might seem antiquated, but were designed to protect a company's most important assets.6. Consider compliance.
Compliance issues have to be considered whether you are going to keep your information on a local server you keep in a safe or a cloud computing platform. Finger-pointing will not satisfy corporate stakeholders or government enforcers.
Published: July 30, 2008 | NYTimes.comAMERICANS today spend almost as much on bandwidth — the capacity to move information — as we do on energy. A family of four likely spends several hundred dollars a month on cellphones, cable television and Internet connections, which is about what we spend on gas and heating oil.
Just as the industrial revolution depended on oil and other energy sources, the information revolution is fueled by bandwidth. If we aren’t careful, we’re going to repeat the history of the oil industry by creating a bandwidth cartel.
Like energy, bandwidth is an essential economic input. You can’t run an engine without gas, or a cellphone without bandwidth. Both are also resources controlled by a tight group of producers, whether oil companies and Middle Eastern nations or communications companies like AT&T, Comcast and Vodafone. That’s why, as with energy, we need to develop alternative sources of bandwidth.
Wired connections to the home — cable and telephone lines — are the major way that Americans move information. In the United States and in most of the world, a monopoly or duopoly controls the pipes that supply homes with information. These companies, primarily phone and cable companies, have a natural interest in controlling supply to maintain price levels and extract maximum profit from their investments — similar to how OPEC sets production quotas to guarantee high prices.
But just as with oil, there are alternatives. Amsterdam and some cities in Utah have deployed their own fiber to carry bandwidth as a public utility. A future possibility is to buy your own fiber, the way you might buy a solar panel for your home.
Encouraging competition is another path, though not an easy one: most of the much-hyped competitors from earlier this decade, like businesses that would provide broadband Internet over power lines, are dead or moribund. But alternatives are important. Relying on monopoly producers for the transmission of information is a dangerous path.
After physical wires, the other major way to move information is through the airwaves, a natural resource with enormous potential. But that potential is untapped because of a false scarcity created by bad government policy.
Our current approach is a command and control system dating from the 1920s. The federal government dictates exactly what licensees of the airwaves may do with their part of the spectrum. These Soviet-style rules create waste that is worthy of Brezhnev.
Many “owners” of spectrum either hardly use the stuff or use it in highly inefficient ways. At any given moment, more than 90 percent of the nation’s airwaves are empty.
The solution is to relax the overregulation of the airwaves and allow use of the wasted spaces. Anyone, so long as he or she complies with a few basic rules to avoid interference, could try to build a better Wi-Fi and become a broadband billionaire. These wireless entrepreneurs could one day liberate us from wires, cables and rising prices.
Such technologies would not work perfectly right away, but over time clever entrepreneurs would find a way, if we gave them the chance. The Federal Communications Commission promised this kind of reform nearly a decade ago, but it continues to drag its heels.
In an information economy, the supply and price of bandwidth matters, in the way that oil prices matter: not just for gas stations, but for the whole economy.
And that’s why there is a pressing need to explore all alternative supplies of bandwidth before it is too late. Americans are as addicted to bandwidth as they are to oil. The first step is facing the problem.
Tim Wu is a professor at Columbia Law School and the co-author of “Who Controls the Internet?”
31 Jul 2007 | www.ibm.com/developerworks
If you manage systems and networks, you need Expect.
More precisely, why would you want to be without Expect? It saves hours common tasks otherwise demand. Even if you already depend on Expect, though, you might not be aware of the capabilities described below.
Expect automates command-line interactions
You don't have to understand all of Expect to begin profiting from the tool; let's start with a concrete example of how Expect can simplify your work on AIX® or other operating systems:
Suppose you have logins on several UNIX® or UNIX-like hosts and you need to change the passwords of these accounts, but the accounts are not synchronized by Network Information Service (NIS), Lightweight Directory Access Protocol (LDAP), or some other mechanism that recognizes you're the same person logging in on each machine. Logging in to a specific host and running the appropriate
passwdcommand doesn't take long—probably only a minute, in most cases. And you must log in "by hand," right, because there's no way to script your password?Wrong. In fact, the standard Expect distribution (full distribution) includes a command-line tool (and a manual page describing its use!) that precisely takes over this chore.
passmass(see Resources) is a short script written in Expect that makes it as easy to change passwords on twenty machines as on one. Rather than retyping the same password over and over, you can launchpassmassonce and let your desktop computer take care of updating each individual host. You save yourself enough time to get a bit of fresh air, and multiple opportunities for the frustration of mistyping something you've already entered.This
passmassapplication is an excellent model—it illustrates many of Expect's general properties:
- It's a great return on investment: The utility is already written, freely downloadable, easy to install and use, and saves time and effort.
- Its contribution is "superficial," in some sense. If everything were "by the book"—if you had NIS or some other domain authentication or single sign-on system in place—or even if login could be scripted, there'd be no need for
passmass. The world isn't polished that way, though, and Expect is very handy for grabbing on to all sorts of sharp edges that remain. Maybe Expect will help you create enough free time to rationalize your configuration so that you no longer need Expect. In the meantime, take advantage of it.- As distributed,
passmassonly logs in by way oftelnet,rlogin, orslogin. I hope all current developerWorks readers have abandoned these protocols forssh, whichpassmasssdoes not fully support.- On the other hand, almost everything having to do with Expect is clearly written and freely available. It only takes three simple lines (at most) to enhance
passmassto respectsshand other options.You probably know enough already to begin to write or modify your own Expect tools. As it turns out, the
passmassdistribution actually includes code to log in by means ofssh, but omits the command-line parsing to reach that code. Here's one way you might modify the distribution source to putsshon the same footing astelnetand the other protocols:Listing 1. Modified passmass fragment that accepts the -ssh argument
...
} "-rlogin" {
set login "rlogin"
continue
} "-slogin" {
set login "slogin"
continue
} "-ssh" {
set login "ssh"
continue
} "-telnet" {
set login "telnet"
continue
...In my own code, I actually factor out more of this "boilerplate." For now, though, this cascade of tests, in the vicinity of line #100 of
passmass, gives a good idea of Expect's readability. There's no deep programming here—no need for object-orientation, monadic application, co-routines, or other subtleties. You just ask the computer to take over typing you usually do for yourself. As it happens, this small step represents many minutes or hours of human effort saved.
tutorial articles in this section describe TCP/IP and related protocols as sequence diagrams. (The sequence diagrams were generated using EventStudio System Designer 2.5).
Articles in this section describe TCP/IP and related protocols as sequence diagrams.
(The sequence diagrams were generated using EventStudio).
WANdoc Open Source Perl=based
WANdoc Open Source is free software that generates interactive documentation for large Cisco networks. It uses syslog and router configuration files to produce summarized, hyperlinked, and error- checked router information. It speeds up the WAN troubleshooting process and identifies inconsistencies in router deployment.
SecuriTeam.com ™ (Archive) - Security News
Understanding IP Addressing Everything You Ever Wanted To Know - By
Chuck Semeria -- good tutorial from 3COM. This
white paper is now available in the 3 pdf's below.
Pages 1 - 21
Pages 22 - 43
Pages 44 - 65
TCP/IP online books Free TCP/IP online books
AW • Professional - Networking Series Catalog Page Books from Addison Wesley, a respected name in technical publication.
Bill Stallings: Home Page Web Site for the Books of William Stallings
Douglas Comer This is the home page of Douglas Comer, the author of the book "Internetworking with TCP/IP".
Illustrated TCP/IP Online version of the book "Illustrated TCP/IP", by Matthew G. Naugle, published by Wiley Computer Publishing, John Wiley & Sons, Inc.
The Internet Companion Online version of the book "The Internet Companion". This book explains the basics of communication on the Internet and the applications available
Internetworking Multimedia This is a online book covering multimedia communication using the Internet
McGraw Hill Networking books A search on networking books published by McGraw Hill.
McGraw-Hill - Bet@ Books Free online prerelease versions of many new books on networking and other topics.
The Mechanics of Routing Protocols An online book published by Cisco Press.
The Network Book A comprehensive introduction to network and distributed computing technologies online
Network Reading List: TCP/IP,UNIX and Ethernet Compilation of links on the Internet relating to TCP/IP, Unix and Ethernet
Networking and Communications Prentice Hall Professional Technical Reference: Special Interests
Routing in the Internet A very comprehensive book on routing, written by Christian Huitema, from the Internet Architecture Board. A must read for those interested on routing protocols
Routing Information Protocols The Network Book, Chapter 3, Section 3. This document is part of the Network Book
TCP/IP and Data Communications Administration Guide An online book, in PDF format, explaining how to setup, maintain and expand a network using the Solaris implementation of the TCP/IP protocols
TCP/IP Network Administration, 2nd Edition Clearly written, this book is a good introduction to the TCP/IP protocols and practical applications.
Troubleshooting TCP/IP This is a sample chapter from the book "Windows NT TCP/IP Network Administration", published by OґReilly and associates which explains how to solve problems related to TCP/IP in a Windows NT environment
Understanding Networking Technologies Online course providing training on a host of networking topics.
Windows NT TCP/IP Network Administration O'Reilly publication covering TCP/IP and NT
Wireless Networking Handbook Online version of the book "Wireless Networking Handbook" by Jim Geier, and published by New Riders, Macmillan Computer Publishing
MCI Arms ISPs with Means to Counterattack Hackers
MCI Arms ISPs with Means to Counterattack Hackers [October 9] MCI introduced today a security product designed to help Internet Service Providers detect network intruders.
The networkMCI DoS (Denial of Service) Tracker constantly monitors the network and then once a denial of service attack has been detected, the product immediately works to trace the root of the attack.
The product is designed to eliminate the time technical engineers spend manually searching for the intrusion. MCI claims the product takes little programming knowledge to find the network intruder.
The DoS Tracker combats SYN, ICMP Flood, Bandwidth Saturation, and Concentrated Source, and the newly detected Smurf hacker attacks.
"Obviously, we can't guarantee the safety of other networks from all hacker activity, but we believe the networkMCI DoS Tracker provides ISPs and other network operators with a powerful tool that will help them protect their Internet assets," Rob Hagens, director of Internet Engineering.
The product is available for free from MCI's Web site.
| The Linux Network Administrators' Guide | FAME Computer Education TCPIP for Idiots Tutorial | RFC1180 | Introduction to the Internet Protocols |
Daryl's TCP-IP Primer Good and up-to-date primer...
Understanding IP addressing -- tutorial from 3Com
**** The Network Administrators' Guide -- the first several chapter contain good introduction to TCP/IP
Contents (fragment)
FAME Computer Education TCPIP for Idiots Tutorial
RFC1180 TCP/IP Tutorial by T. Socolofsky & C. Kale January 1991 (63 KBytes) -- old, but still decent is a tutorial (UK mirror RFC 1180)
TCP-IP and IPX Routing tutorial (mirror TCP-IP and IPX routing Tutorial )
Introduction to the Internet Protocols by Charles L. Hedrick. 3 July 1987 (Rutgers University). See also a mirror Introduction to TCPIP
Fast Guide to Subnets by Chuck Semeria (3Com)
Integrating Your Machine With the Network - good guide from USAIL
PC Magazine PC Tech (A Beginner's Guide to TCPIP)
An excellent collection of lecture notes at the University of Massachussetts. Detailed description of TCP and IP protocol design and implementation
Useful links -- The Network Management Online Library
PC Connectivity - TCP-IP, Winsock & Dial-up Internet Access -- useful but outdated
Charm Net Personal IP Page -- a lot of useful links
TCP-IP, Index A GUIDE TO TCP/IP INTERNETWORKING
Integrating Your Machine With the Network - very good guide from USAIL
Doing remote computing by issuing commands through electronic mail
Old and broken links
***+ TCP-IP Tutorial and Technical Overview -- a pretty decent and up to date IBM Redbook PDF
Table of Contents (old version was in HTML, now only PDF is available from the IBM site)
Part 1. Architecture and Core Protocols
Part 2. Special Purpose Protocols and New Technologies
Part 3. Connection Protocols and Platform Implementations
Copyright © 1996-2009 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Disclaimer:
Last modified: August 25, 2009