Mira, hace un tiempo hice eso, si tienes en tu nodo un cisco, todo lo tendrás resuelto sin tener que tocar los routers de tus dependencias. Si lo que tienes es otro router, entonces necesitarás tener el nombre y el password de la comunidad snmp de cada uno de los routers y podrás hacer el mismo procedimiento que tienes en tu router actual y podras medir ese tráfico que necesitas.
Saludos cordiales, Whilo -----Mensaje original----- De: gutl-l-boun...@jovenclub.cu [mailto:gutl-l-boun...@jovenclub.cu] En nombre de gutl-l-requ...@jovenclub.cu Enviado el: sábado, 05 de marzo de 2011 8:39 Para: gutl-l@jovenclub.cu Asunto: [!! SPAM] Resumen de Gutl-l, Vol 11, Envío 15 Envíe los mensajes para la lista Gutl-l a gutl-l@jovenclub.cu Para subscribirse o anular su subscripción a través de la WEB https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l O por correo electrónico, enviando un mensaje con el texto "help" en el asunto (subject) o en el cuerpo a: gutl-l-requ...@jovenclub.cu Puede contactar con el responsable de la lista escribiendo a: gutl-l-ow...@jovenclub.cu Si responde a algún contenido de este mensaje, por favor, edite la linea del asunto (subject) para que el texto sea mas especifico que: "Re: Contents of Gutl-l digest...". Además, por favor, incluya en la respuesta sólo aquellas partes del mensaje a las que está respondiendo. Asuntos del día: 1. Sobre MRTG (Ángel Luis Otero Medina) 2. Re: Sobre Pidgin (Juan Carlos) 3. Por qué no usar Microsoft Exchange (Mauricio López) 4. Moderadores Evento Flisol 2011 (Pablo M. Drake) 5. Como migrar de un active directoryaun ldap (Islay Gallo Vaillant) ---------------------------------------------------------------------- Message: 1 Date: Fri, 04 Mar 2011 13:43:01 -0500 From: Ángel Luis Otero Medina <ad...@ssp.ecc.cu> Subject: [Gutl-l] Sobre MRTG To: Lista cubana de soporte tecnico en Tecnologias Libres <gutl-l@jovenclub.cu> Message-ID: <1299264181.8058.4.camel@localhost> Content-Type: text/plain; charset=UTF-8 Buenas tardes, tengo una duda con respecto al mrtg que es lo que uso para medir el trafico del ancho de banda en mi Router, perfecto, ahora me viene la idea de poder medirselo tambien a los otros routers de las demas depedencias de mi empresa, esos routers no llegan directamente a mi pero si estan en mi VPN la cual esta configurada para hacer cada router independiente, cada uno de ellos incluyendo el mio va a una puerta ATM que esta en mi empresa nacional, la duda concretamente es si en el mismo servidor que estoy midiendo el ancho de banda de mi router tambien puedo medir aparte el de las otras dependencias. ? Saludos -- ------- Ángel Luis Otero Medina ECC SS MIC Correos de Cuba Administrador de Redes Tel:53-41-327502 ext 107 mail: ad...@ssp.ecc.cu ------------- Servicios Telematicos de la Red ssp.ecc.cu Empresa Correos de Cuba. (MIC). Sancti Spíritus Contactenos por el Mail ad...@ssp.ecc.cu --------------------------------------- ------------------------------ Message: 2 Date: Fri, 04 Mar 2011 16:16:37 -0500 From: Juan Carlos <jchernan...@ca.mfp.gov.cu> Subject: Re: [Gutl-l] Sobre Pidgin To: Lista cubana de soporte tecnico en Tecnologias Libres <gutl-l@jovenclub.cu> Message-ID: <4d7156b5.5040...@ca.mfp.gov.cu> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" El 03/03/2011 09:11 p.m., KZKG^Gaara escribió: > El 03/03/11 09:10, Manuel Salgado escribió: >> Saludos nuevamente: >> Me he instalado la version 2.4.3 de Pidgin en Debian, pero hay un >> detalle >> que no he logrado aun como cuando lo tenia en Windows. Es que arranque y >> conecte automaticamente cada vez que inicie sesion, pues tengo que >> hacerlo >> manualmente. >> Gracias de antemano. > Agrégalo a las aplicaciones de inicio en : > Sistema-»Preferencias-»Aplicaciones al Inicio > > ______________________________________________________________________ > Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. > Gutl-l@jovenclub.cu > https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l > > > __________ Información de ESET NOD32 Antivirus, versión de la base de > firmas de virus 5914 (20110228) __________ > > ESET NOD32 Antivirus ha comprobado este mensaje. > > http://www.eset.com > > > > Men mira en las versiones de pidgin que he usado en el menu complementos el trae una opción que es para que arrance con el sistema buscala y activala y listo.... -- Juan Carlos Hernández Gallardo Administrador de Redes Dirección Provincial de Finanzas y Precios Nodo - Ciego de Ávila E-mail: jchernan...@ca.mfp.gov.cu Telf:0133-224712 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: <http://listas.jovenclub.cu/pipermail/gutl-l/attachments/20110304/29485c20/attachment.htm> ------------------------------ Message: 3 Date: Fri, 4 Mar 2011 17:02:13 -0500 From: Mauricio López <mlope...@gmail.com> Subject: [Gutl-l] Por qué no usar Microsoft Exchange To: Listacubana de soporte tecnico en Tecnologias <gutl-l@jovenclub.cu> Message-ID: <20110304220213.GA15600@mauricio-desktop> Content-Type: text/plain; charset=iso-8859-1 Enlace original http://bsdly.blogspot.com/2011/02/problem-isnt-email-its-microsoft.html The Problem Isn't Email, It's Microsoft Exchange The takeaway: don't pretend your appointment book can handle your email. And don't blame the Internet for all the compatibility issues. The main problem is Microsoft Exchange. I care about email. In fact, a large part of how I have made a living over the years has depended on a reliable email service. I get a lot of email, and I send my fair share of it too - some of it is correspondence directly related to whatever I'm working on at the moment, some of it is personal, quite a bit comes from topic-oriented mailing lists such as openbsd-misc, and a large chunk of my mail archive consists of automatically generated mail sent by systems in my care. I've also been known to treat email much the same as other correspondence, rarely if ever deleting messages. When the mailboxes became too unwieldy I would transfer some of the contents to archive storage. I've become convinced that a large part of the reason I don't mind dealing with large volumes of email is that I started doing it before Microsoft became an actor in the Internet email market. Way back in the late eighties and early nineties, email of the Internet, TCP/IP, kind would be handled by some sort of Unix box (a BSD or, by the mid-nineties, a Linux variant, perhaps) that would frequently offer shell command line access, but more likely than not also email reading via POP or IMAP interfaces. And it worked. Users who insisted on (or needed to be on) a Microsoft desktop could be persuaded to install a useful email client such as Eudora (now defunct but fortunately Qualcomm donated the code base to Mozilla for integration in Thunderbird), and for mailboxes that became too unwieldy, the advice would be to just move content to mailboxes that Eudora wouldn't load into memory by default, such as the ubiquitous Inbox. Over the years the volumes of and the nature of email changed gradually, so along the way we learned to deal with spam and mail-borne Microsoft worms by installing content filtering and setting up other tools. Still, everywhere I worked, apart from the unavoidable but infrequent freak incidents SMTP email was considered reliable, and your email archive was just that. >From other parts of the world we would hear every now and then stories about >the death of email, and recently even a largish IT company announced that they were planning to get rid of all email in the near future. Email, the story goes, is just too time consuming and disruptive. I never quite understood what they were on about. Then not too long ago I started working regularly in an environment where email is done the Microsoft way, via Exchange and Outlook. And it has struck me that they're right: If your email experience is via Exchange and Outlook, the net effect is both time consuming and disruptive. Forced to work with an all-Microsoft desktop for the first time in years (where my most frequently used application by far is putty.exe, but that's beside the point here), I found Outlook's user interface clunky and with frankly insane default settings ("rich text" by default, newest messages on top and positively deranged quoting setups, more about that later) that were for the most part fortunately changeable, at least on a per mailbox basis. The first revelation came when I heard a co-worker praise newer Microsoft Office releases "because 2007 and newer has discussions". I was forced to imagine how life must have been like without threading as we've tended to call it on the USENET and mailing lists since, well, the late 1980s. Outlook's predecessor Microsoft Mail of course did not support threading, but I suppose any plans to support threading via References: headers and suchlike received a major blow when the translators of MSMail decided not to leave the RFC-dictated "Re:" prefix alone, but rather translate it for local language versions and lead the way to the "Re: SV: Antw: VS:" and so on cascades we see in the Subject: fields for correspondence between users of Microsoft mail clients and others. No big surprise then, that when Microsoft decided to "invent" threading for their messaging products, they again ignored the RFC-compliant References: header and chose to implement their very own version based on a set of X-something headers that appears to make the threading a local-to-this-Exchange-server (and Outlook clients only) thing. Messages that do not retain the X-something headers regularly show up as separate "discussions". All this is to a Unix-head much like the "Recall" functionality that always draws smiles on mailing lists. Being robbed of any easy way to track the relationships between messages in your mailboxes is bad enough, but there's more. Even with a limited sort of threading in place (even one that would break at the slightest interference from outside software), the damage had already been done by software that introduced counterproductive, confusing and time consuming response practices. For reasons that have never become entirely clear to me, the developers of Microsoft email client software decided that direct and limited quoting of text from previous messages was not a priority. So rather than build on earlier work where we would have exchanges like From: First Correspondent <first.correspond...@onecompany.nx> To: Second Emailer <second.emai...@otherplace.nx> Subject: A most enlightening message Dear Second, Here I offer an important insight that I would like to share. Followed with random commentary that may or may not be important. I hope you agree this was worth sharing. Yours, First where a typical response from Second would typically be something like this, From: Second Emailer <second.emai...@otherplace.nx> To: First Correspondent <first.correspond...@onecompany.nx> Subject: Re: A most enlightening message First Correspondent <first.correspond...@onecompany.nx> writes: > Here I offer an important insight that I would like to share. Thanks for sharing that! The next bit was really about something else entirely, but is probably worth discussing over refreshments at an appropriate time. > I hope you agree this was worth sharing. Oh, definitely! We'll get plenty of good out of this as time goes by. Be seein' ya, Second, jr they chose a different approach entirely. Keep in mind that other parts of the world that were already used to email and related forms of communication such as Usenet news, where exchanges like these were commonplace and gave a reasonable certainty as to who said what, when. What Microsoft did instead was to introduce a wholly new convention for email responses. The details vary over the various versions, but the main parts were to wrap any text information in pseudo-html formatting and place the entire previous message after the present correspondent's signature, with the cursor for the user to input text at the top. Inline quoting like in the exchange I quoted earlier was tricky bordering on impossible, and adventurous users would resort to tricks like "my parts are the ones in magenta", only to discover that the carefully hand-painted text would fail to render correctly on any other software than their own version, down to the minutest patch level. Thus was born the age of all-inclusive top-posting, where deciphering the true meaning of any of the paragraphs on top of the message could take more moments than you really have at your disposal, the time needed to decipher the cascade of earlier messages included. Not only would the ever-expanding, all-inclusive (but actually rather unreliable and far from tamper-proof) discussion-in-a-message convention confuse all readers involved, it also meant that the text and any file attachments would be stored multiple times, many times over for long discussions. It would take only a minimally uncharitable view of the average C?O's intellectual capacity to suggest that this was a prime mover behind the intense rush to "data deduplication" in storage marketing literature a few years ago. Which takes us to the next item: Storage. Taken in semi-random order, the next hurdle for a Microsoft email user to overcome is storage. Outlook by default uses its own binary format for local message storage, know as PST files or Personal Storage Table files as the informative Wikipedia entry explains. In some configurations all mail is stored in a database of sorts on the Exchange server, and the user may or may not have the option to save messages to local PST files to work around space limitations on the server. It is not uncommon for Exchange admins to turn off users' ability to save messages to PST files. One major reason is that more likely than not any saved PST file will end up on the end user's computer, with the consequence that potentially important messages may end up being backed up infrequently, if at all. Other reasons to avoid PSTs are size limits (originally 2GB but larger in newer releases), but the thing that tends to scare people the most are horror stories of data corruption to the point of absolute unrecoverability. As in gigabytes of your business or personal life gone, due to a scrambled PST file. There is anecdotal evidence that missing or scrambled PST files are a big headache for those who for various reasons want to look into the inner life of the Bush 43 administration. So for records keeping involving your email, you're in a bind: Your mailbox size is likely to be limited -- every Exchange admin knows that large mailboxes will hurt performance, impacting all users of that server -- and the only way to save messages offline is a known-unsafe method. As far as I have been able to find out, there is no easy way (other than extracting messages to a separate system, say via IMAP) to export mail from the Microsoft product combo to any text or non-microsoft mailbox format. Now weigh those practical considerations against legislation that dictates all business related correspondence be kept on file for a matter of several years. The exact number of years varies by location, but unless you've purchased one of the add-on solutions for archiving, you will be struggling to keep in line with requirements. It all comes down to the shortsightedness or intellectual shallowness of Microsoft Exchange's designers, way back then. It does make sense that your appointment calendar application should be able to send and receive email, and it kind of makes sense that your appointments are within easy reach from your email client. Those facts do not, however, dictate that the appointments calendar and your email archive should share a common storage backend. In fact, it's likely that the decision to merge the email storage and appointments storage into one is the direct cause of many of the inefficiencies of Microsoft Exchange. In one recent incident involving a user mailbox of perhaps a couple of gigabytes, where the bulk of the data was made up of an estimated (since Outlook never managed to display totals before freezing) 1.5 million messages of about one kilobyte each, even deleting the messages using an Outlook filtering rule (the content was not of a nature that required long term storage) literally took weeks, typically proceeding at a rate of one message per second early in the process, speeding up to somewhere in the five to ten messages per second rate near the end. Fortunately the user in question was able to access email functionality via the Outlook web access interface while deletion proceeded, but anecdotal evidence suggests that the workload had measurable performance impact on other hosts attached to the same SAN. Even if you tackle the storage hurdle, you more than likely will be tripped up by other inanities in the software design. There are bound to be other pitfalls, but here is my personal list of things that continue to irritate me (in addition to the default "rich text" formatting), coming as I do from the outside world: Using Outlook it appears to be impossible to see what your From: address will be before you send the message. The effect is sometimes quite bizarre, in my case since the site has several domains, I of course ended up signing up to several mailing lists with a wrong address, banishing my posts there to moderator queues until I was able to study the real mail headers on a non-Microsoft system. Also, Outlook is overly helpful in filling in adress fields such as To: and Cc: from common address books and Active Directory, leading in at least one case I know of to a supposed-to-be-private message to be sent to every mailbox in a largish corporation. That's when you learn that after the first reply, retracting the message won't actually work. And no rant about Exchange would be complete without mention of the largely information-free bounce messages the system generates for non-delivery. A significant portion of the spamtrap addresses I use have been fished out of bounce messages, and the Exchange ones stand out as the ones practically guaranteed to exclude any information about where the triggering message came from, or when. Summing up, if you're an executive who feels that your organization is saddled with inefficient email processing and dubious archiving, the likely culprit is not email as such, but rather the poorly constructed application some unscrupulous sales person inserted in your network for you. Changing to a standards compliant, preferably open source, alternative is likely to save your organization costs at all levels, including hardware and software acquisition and maintenance costs as well as significant personell time. At the same time a move to a standards compliant, open source solution will likely leave you in a better position with respect to security, information consistency and verification. A full treatment of email as a business tool would have had at least one column of similar length as this one on each of these topics, and I may return to those in future columns. In the meantime, if inefficient emailing bothers you, you may need to realize that a large part of your problem is Microsoft Exchange. -- Saludos de Mauricio López-Quintana Conesa Administrador de Redes Dirección de Patrimonio Oficina del Historiador ------------------------------ Message: 4 Date: Thu, 03 Mar 2011 21:17:27 -0500 From: "Pablo M. Drake" <adminen...@infomed.sld.cu> Subject: [Gutl-l] Moderadores Evento Flisol 2011 To: Lista de Soporte GUTL <gutl-l@jovenclub.cu> Message-ID: <4d704bb7.4060...@infomed.sld.cu> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Con motivo del evento internacional Flisol 2011, se convoca a los miembros activos de la comunidad de SWL de Ciudad Habana para participar como moderadores del evento donde se realizara el Install Party (Fiesta de Instalación). Todos los interesados en participar o dar su aporte de un modo u otro háganme llevar por esta vía su respuesta. En el portal de GUTL [1] esta publicada toda la información al respecto del evento. Ya se esta trabajando con todo lo relacionado a la divulgación y a los nuevos aspectos a tratar en este festival de instalación. Se hace necesario la confirmación de este correo para realizar la distribución del trabajo y las coordinaciones necesarias para que este evento quede con la calidad y el nivel que esperamos, debido a la importancia que este tiene para la comunidad. Esta convocatoria es abierta para todos los miembros activos de la comunidad o cualquiera que desee colaborar e ingresar a la misma. Es necesario también que respondan lo antes posible pues ya comenzamos las labores y las gestiones necesarias en vista al Flisol 2011 Saludos Pablo Mestre Moderador Flisol Habana-Cuba 2011 [1] http://gutl.jovenclub.cu -- Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema Nacional de Salud. La persona que envia este correo asume el compromiso de usar el servicio a tales fines y cumplir con las regulaciones establecidas Infomed: http://www.sld.cu/ ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: <http://listas.jovenclub.cu/pipermail/gutl-l/attachments/20110303/01cff89f/attachment.htm> ------------------------------ Message: 5 Date: Mon, 28 Feb 2011 01:33:40 +0100 From: "Islay Gallo Vaillant" <desarro...@mn.mn.co.cu> Subject: [Gutl-l] Como migrar de un active directoryaun ldap To: "'Lista cubana de soporte tecnico en Tecnologias Libres'" <gutl-l@jovenclub.cu> Message-ID: <000501cbd6df$27082f50$75188df0$@mn.co.cu> Content-Type: text/plain; charset="iso-8859-1" Buenas alguien de la lista sabe como exportar la estructura de un AD 2003 server para un ldap...o como exportar la estructura para un archivo ldif... Gracias de antemano ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: <http://listas.jovenclub.cu/pipermail/gutl-l/attachments/20110228/480871a0/attachment.html> ------------------------------ _______________________________________________ Gutl-l mailing list Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l Fin de Resumen de Gutl-l, Vol 11, Envío 15 ****************************************** ______________________________________________________________________ Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba. Gutl-l@jovenclub.cu https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
