[ilugd] Next ILUG-D meeting 2pm, Sun, Jan. 28th.
Hello, The next ILUG-Delhi meeting will be held in the JNU Bio-Informatics Centre, at 2pm on Sun., July 28th. Here is the current list of agenda items. Will the responsible person please confirm to me off-list, and, if possible, send me an abstract of a couple of lines. Also, please feel free to send me any more items. 1. E-zine: Atul Jha 2. Training workshops at RKGIT: Gaurav Mishra 3. Cross-platform, cross-language development: Gora Mohanty I will talk about how to easily develop applications that can be shared between multiple programming languages, and used on different platforms. The presentation will cover the use of SWIG, GTK, Mono, and Python, using the example of a Hindi spell-checker, and a GUI interface, based on the open-source aspell spell-checking engine. Regards, Gora ___ ilugd mailinglist -- ilugd@lists.linux-delhi.org http://frodo.hserus.net/mailman/listinfo/ilugd Archives at: http://news.gmane.org/gmane.user-groups.linux.delhi http://www.mail-archive.com/ilugd@lists.linux-delhi.org/
[ilugd] [COMMERCIAL] Immediate requirement of Linux System Administrator at HCL - Noida
Linux System Administrator's required. Experience: 6 Years or more Education:B.E/3 years Diploma Job Description: Hands-On expertise on System administration in a large data-center kind of environment in Redhat-Linux. It is preferred to have Unix multi-skilling of the following OS i.e. Solaris / AIX. Hands On expertise in maintaining troubleshooting Enterprise Redhat Linux for 5 years preferred. Hands-On Experience in setup troubleshooting of NIS / NIS + / NFS / Automounter / SSH / SUDO/ RSYNC/ SAMBA/ Sendmail / Proxy / Apache/ NNTP/ RCS/ Kickstart/ LVM/ Hardware Raid/ ftp/ Linux Clustering/ and compiling / upgrading Linux kernel using source as well as rpm. Knowledge of system performance tuning. Previous experience on Veritas Netbackup. Knowledge of the HP Open View. Hands-On Experience on Korn shell and perl scripting languages. Experience with configuring, maintaining, and troubleshooting a TCP/IP network. Experience in one of the trouble ticketing systems like Remedy etc. Ability to Handle Technical Escalations. Ability to conduct technical trainings. Process Orientation Good Documentation Skills. Understanding of ITIL terminology. Location : Noida Contact Information: - Atul Kumar [EMAIL PROTECTED] Mob: +91 9810010393 DISCLAIMER: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. --- ___ ilugd mailinglist -- ilugd@lists.linux-delhi.org http://frodo.hserus.net/mailman/listinfo/ilugd Archives at: http://news.gmane.org/gmane.user-groups.linux.delhi http://www.mail-archive.com/ilugd@lists.linux-delhi.org/
[ilugd] [Fwd: Re: [svlug] Firewalls?]
A good mail about security from a discussion about firewalls that have been going on in the SVLUG list Original Message Subject: Re: [svlug] Firewalls? Date: Tue, 23 Jan 2007 23:47:47 -0800 From: Rick Moen [EMAIL PROTECTED] To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Quoting Raj Shekhar ([EMAIL PROTECTED]): I did not get the part about the wrong problem. Can you explain what you mean by that ? Glad to. Security measures aim to handle anticipated _threat models_ -- scenarios of harm: Logically, before you can design (or pick) a security measure to implement, you need to articulate what threat you're trying to protect against, why it's a threat, what's at risk, why it's a more-significant threat than other risks you could be worrying about, etc. All of those measures you spoke of appear to assume implicitly that brute-force dictionary attacks across the Internet against your sshd -- e.g., the dozen bursts / day of about 23-30 joe-username login attempts each that typically hit every public IP on the Internet -- are a serious threat. Are they? For the sake of discussion, imagine that some attacker spends his ssh-attempting resources against only _your_ IP, and attempts to work constantly at progressing in some fashion through the userspace of all possible Linux usernames and passwords. (This never actually happens, but could in theory.) Bear in mind the considerable lagtimes within and between failed attempts. So: Guesstimate how long, on average, it's going to take to crack one of your login accounts that way. (For the sake of discussion, ignore the fact that your /var syste growing to stupendous sizes because of the sudden mountain of entries in /var/log/auth.log, which in fact would either be a tipoff or knock your system over.) It's pretty much going to be impossible for the attackers to get into your system that way, within geologic timescales -- unless you or one of your users happens to have used some unbelievably easy to guess username/password pairing. You might be able to see this coming: If your system allows users to employ some unbelievably easy to guess username/password pairing, isn't _that_ your actual fundamental problem, and not the doorknob-twisting so-called attacks? In my personal view, measures like you described (and I know such recommendations are made really, really frequently, so I'm not intending to single you out) lack any real point because they designate as a serious threat something that, realistically, is not actually significant at all, on any halfway reasonably run system. You could actually predict that by looking at what those ssh attackers typically try: They (or rather, their scripts) attempt only about a score of really lame username/password pairs, attempting to find some basically wide-open system, and the give up and move on to the next IP. Unfortunately, many Linux people don't stop and do threat analysis before designing and implementing suggested remedies. That's how we get massively overbuilt, over-complex systems that are aimed against things that aren't even really threats, while other _real_ threats don't get addressed for lack of time and resources. Security's a difficult problem, and also requires an attitudinal approach that's alien to most people, including particularly programmers. Here's an example: In cryptography, all other things being equal, the newest cipher designs from respected professional cryptographers should be expected to be stronger than the older ones, right? After all, the new designs are based on learning from the experience in designing and implementing the older ones. (We're counting, here, only older ciphers that haven't been cracked.) However, the exact opposite is actually the case: Older uncracked ciphers merit much greater trust than do newer uncracked ciphers, because they have a much longer history of surviving inventive, determined attacks of all sorts from other cryptographers. E.g., Bruce Schneier will tell you that his relatively new Twofish cipher is _probably_ a really good example of symmetric crypto, but is way too unseasoned to put much faith in yet, and that you're much better off relying on 3DES or Blowfish. And I predict that nine out of ten coders would tell you the newer ciphers will tend to be better. ___ svlug mailing list [EMAIL PROTECTED] http://lists.svlug.org/lists/listinfo/svlug -- raj shekhar facts: http://rajshekhar.net | opinions: http://rajshekhar.net/blog I dare do all that may become a man; Who dares do more is none. ___ ilugd mailinglist -- ilugd@lists.linux-delhi.org http://frodo.hserus.net/mailman/listinfo/ilugd Archives at: http://news.gmane.org/gmane.user-groups.linux.delhi http://www.mail-archive.com/ilugd@lists.linux-delhi.org/
[ilugd] Daylight Saving Time
The United States Congress passed an energy policy act which will change the start and end dates for daylight savings time (DST). The changes go into effect March 2007. Microsoft has released patches for the same. Do we need to update anything on linux boxes ? Regards Mangesh ___ ilugd mailinglist -- ilugd@lists.linux-delhi.org http://frodo.hserus.net/mailman/listinfo/ilugd Archives at: http://news.gmane.org/gmane.user-groups.linux.delhi http://www.mail-archive.com/ilugd@lists.linux-delhi.org/
Re: [ilugd] Daylight Saving Time
Do we need to update anything on linux boxes ? Regards Mangesh Yes you would probably need one the DST for USA is * Start date: Second Sunday of March * End date: First Sunday of November a small test to know if your distro needs a patch , i am checking for my time zone , it will vary for others the output should be something as follows for a distro which does not need a patch $/usr/sbin/zdump -v PST8PDT |grep 2007 PST8PDT Sun Mar 11 09:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 PST isdst=0 gmtoff=-28800 PST8PDT Sun Mar 11 10:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 PDT isdst=1 gmtoff=-25200 PST8PDT Sun Nov 4 08:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 PDT isdst=1 gmtoff=-25200 PST8PDT Sun Nov 4 09:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 PST isdst=0 gmtoff=-28800 and it will be something like this for a distro which needs a patch $/usr/sbin/zdump -v PST8PDT | grep 2007 PST8PDT Sun Apr 1 09:59:59 2007 UTC = Sun Apr 1 01:59:59 2007 PST isdst=0 gmtoff=-28800 PST8PDT Sun Apr 1 10:00:00 2007 UTC = Sun Apr 1 03:00:00 2007 PDT isdst=1 gmtoff=-25200 PST8PDT Sun Oct 28 08:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 PDT isdst=1 gmtoff=-25200 PST8PDT Sun Oct 28 09:00:00 2007 UTC = Sun Oct 28 01:00:00 2007 PST isdst=0 gmtoff=-28800 for more info check dstpatch.com cheers Satya ___ ilugd mailinglist -- ilugd@lists.linux-delhi.org http://frodo.hserus.net/mailman/listinfo/ilugd Archives at: http://news.gmane.org/gmane.user-groups.linux.delhi http://www.mail-archive.com/ilugd@lists.linux-delhi.org/
