infrastructure October 2011

infrastructure@lists.fedoraproject.org

36 participants
39 discussions

Plan for tomorrow's Fedora Infrastructure meeting (2011-10-20)
by Kevin Fenzi 19 Oct '11

19 Oct '11

The infrastructure team will be having it's weekly meeting tomorrow 2011-10-20 at 1900 UTC in #fedora-meeting on the freenode network. NOTE that I will be out tomorrow/friday, hopefully someone else can run the meeting in my absense. ;) Suggested topics (suggested by whom): * New folks introductions and Apprentice tasks. * Upcoming Tasks/Items 2011-10-20 - 2011-10-21 - kevin out on PTO. 2011-10-24 - send out nag about pass/keys change 2011-10-25 - 2011-11-08: Final change freeze 2011-11-01 mail fi-apprentice folks. 2011-11-08: Fedora 16 release. * Meeting tagged tickets: https://fedorahosted.org/fedora-infrastructure/report/10 Submit your agenda items, as tickets in the trac instance and send a note replying to this thread. More info here: https://fedoraproject.org/wiki/Infrastructure/Meetings#Meetings Thanks kevin

1 0

2factor auth
by Seth Vidal 19 Oct '11

19 Oct '11

Hi all, I've been reading and noodling around with some of the 2factor auth (2fa) mechanisms available - trying to figure out which ones fit for our users, our use case, and our mandate (open source ftw). OTP (TOTP or HOTP) appears to be the most common type. TOTP is what google authenticate uses and is more or less what the rsa securids, etc use. The biggest problem with OTP is that it's a symmetric key that both ends have to know (in the clear) to generate or validate the password. This means that if your server side gets compromised then everyone's keys are immediately invalidated. The second problem is that you need some sort of device that can run either an ios or an android app to generate the passwords from the secrets. ( Curiously enough you don't really need that - you can use the secret on your computer to make the passwords too using some really simple code - especially the TOTP ones. However, at that point it is not 'something you know and something you have (on another device that is not connected to your computer) it is something you know and a piece of software you run on your computer which, obviously, anyone who cracks your computer can then use to login as you - but I digress) Yubikeys - which we are already using - not fabulously, is a combination of an assortment of those. The biggest problems with the yubikeys is: 1. getting them into people's hands 2. getting another one into their hands when they lose or break the last one. 3. the company who makes them being relatively small and afaict the only company who makes them. 4. kinda fiddly. Now - we could just use the tools that google offers - which are open source - at: http://code.google.com/p/google-authenticator/ but the problem there is that it requires storing all of the secrets on any/every machine you would need to login to. Since the secrets in OTP are clear and vulnerable it makes that an unacceptably high risk, imo, to put them on all of our machines. So I started hunting around and I think I have some of a solution to this part of the problem: Here's how it should work: - you go to login - you're prompted to supply your normal/regular password + your one-time-password(otp) (all on one line - which means not having to hope that the apps can cope with this) - you go to your phone or other ios/android device. Open the app that gives you your otp and input that with your password. - the login is passed to a pam module which relays this auth-attempt to a cgi housed on our fas servers (or potentially in multiple locations for network-dispersal) (the cgi runs over https, obviously - maybe authenticated with client-side ssl cert?) - the cgi checks the otp and replies 'yay, nay, or broken'. - you are logged in or reprompted or whatever.; linotp implements most of this -but they've added a lot of bits to it that we probably don't need and their pam module looks to be about 90%+ of what we do need. So that might be where we go from here. Now - how do we get people their otp secrets, etc: That depends on who 'people' is - if people is really only people who can sudo places then, imo, we do them all by hand - generating them (or regenerating them) as we go. This is mainly b/c setting up too much infrastructure to support this is just a fools errand if we're only talking about 50-100 people to deal with and having a human in there tends to make it harder to spoof. If 'people' is everyone who can commit to fedora then we've got to figure out how to do it nicely: one option could be something like: https://github.com/nathforge/pyotp integrated into fas. Another option might be to send out OTP secrets encrypted to each user using their gpg identity. One final thing: Ricky Zhou mentioned this group: duosecurity.com. They have a neat system and set of apps for smart phones/devices which circumvent the problems with otp secrets being exposed. But it requires that the device you have is connected to the internet in some way - which is tricky, to say the least. Implementing something like their system should be possible - but we're going to need someone who is an android and/or ios app developer to help. So - my questions are: 1. Is requiring an android/ios device too onerous? 2. Does the 'here's how it should work' section above make sense/seem secure to everyone? 3. who should we be requiring to use this? sysadmin-main? sysadmin-*, anyone with a shell account? Would it make sense to make ssh keys + OTP auth to get onto fedorapeople.org at all? what about fedorahosted? need input. :) -sv

11 26

احصل على امكانية الوصول الى صوري وأكثر من ذلك
by Karm Al-Bustany 18 Oct '11

18 Oct '11

مرحبا، لقد انشات صفحة شخصية على Netlog مع صوري وملفات الفيديو والمدونات والفعاليات و اريد اضافتك كصديق و يمكنك مشاهدة صفحتي الشخصية .في البدايه تحتاج للتسجيل على Netlog ! عند تسجيلك للدخول، يمكنك انشاء صفحة شخصية خاصة بك. إلقاء نظرة: http://ar.netlog.com/go/mailurl/-bT0yMTk5MTYxNDEwJmw9MSZnbT0xMiZ1PSUyRmdvJT… تحياتي ، Karm ---------------------------------------------------------------- لا تريد تلقي دعوات من اصدقائك بعد؟ http://ar.netlog.com/go/mailurl/-bT0yMTk5MTYxNDEwJmw9MiZnbT0xMiZ1PSUyRmdvJT… Don't want to receive invitations from your friends anymore? http://ar.netlog.com/go/mailurl/-bT0yMTk5MTYxNDEwJmw9MyZnbT0xMiZ1PWh0dHAlM0…

1 0

Re: 2factor auth
by Adam M Dutko 17 Oct '11

17 Oct '11

These problems we are discussing are difficult. The somewhat obvious part is that I think in the end no single solution will be the best. Using a phone based solution is scary. I cannot understand why one would want to base their security on a transient and expensive device. Such devices are easily lost, easily damaged, and as crackers are discovering, breakable, just like any other software based system. These same reasons are why I believe "fobs," "tokens" or whatever you want to call them, are also not an optimal solution. However, unlike phones, they are inexpensive, disabled with minimal pain/inconvenience as compared to wiping a phone, and although potential targets for theft, not as big of a target as a much more expensive devices like phones. Likely fob thieves would know what they are doing (which is scary in itself), but they are most likely less numerous than would-be phone thieves. The primary concerns I have about any system relate to how easy is to "rebase" aspects of the solution when different pieces are compromised; how expensive is the solution in terms of total cost expressed in dollars (new phone or token), time (administrative, transit, etc.) and resources (recreating the environment from scratch). Some of the suggested solutions rely on third parties so minimizing these dependencies when possible is probably a good idea. What happens if Oracle succeeds and Android is hosed in a few years (highly unlikely but possible)? What happens when YubiCo dissolves? What happens when Google pulls support for their OTP system (again unlikely, but possible)? What happens when solution x is compromised like the recent RSA breaches? We obviously cannot predict the future, so I guess I'm wondering what matters the most to those who will actively be using the solution? Like Seth, and other mention, what groups are we covering? and what can we require of each of those groups? Is it fair to say if you want to be an admin you have to have the dough to pay for a phone and pay for a service plan? I don't know, but it will shape the demographic in certain, and possibly, unfortunate ways. I also had a discussion with a friend who does a lot of reverse engineering. He mentioned the YubiKey hardware is trivial and that it would probably be more difficult to reverse engineer the algorithms involved in generating the OTP. -- Take care! -Adam

2 1

audit messages to syslog
by Kevin Fenzi 15 Oct '11

15 Oct '11

Greetings. I'd like to try stopping auditd and having selinux audit messages go to rsyslog (and thus be captured over on log02). This way we can have epylog process those logs, they can be remote so we can have a remote copy of them. This may result in some noise, but I think we can improve the epylog selinux module and fix things, and it gives us another audit trail of things happening on the machines where selinux is enabled. I think this should do it (in such a way we can easily back it out): diff --git a/modules/audit/manifests/init.pp b/modules/audit/manifests/init.pp index 30f19c7..ced28a1 100644 --- a/modules/audit/manifests/init.pp +++ b/modules/audit/manifests/init.pp @@ -6,8 +6,8 @@ class audit::auditd { include audit::package service { auditd: - ensure => running, - enable => true, + ensure => stopped, + enable => false, require => Package['audit'] } Thoughts? downsides? Alternate plans? kevin

4 7

Plan for tomorrow's Fedora Infrastructure meeting (2011-10-13)
by Kevin Fenzi 13 Oct '11

13 Oct '11

The infrastructure team will be having it's weekly meeting tomorrow 2011-10-13 at 1900 UTC in #fedora-meeting on the freenode network. Suggested topics (suggested by whom): * New folks introductions and Apprentice tasks. * Password/Ssh-key/Cert reset fallout * Upcoming Tasks/Items (nirik) ? - make a new bastion02/nuke bastion04 ? - move app02/04 2011-10-09 Remove inactive fi-apprentice people. 2011-10-25 - 2011-11-08: Final change freeze 2011-11-01 mail fi-apprentice folks. 2011-11-08: Fedora 16 release. * Meeting tagged tickets: https://fedorahosted.org/fedora-infrastructure/report/10 Submit your agenda items, as tickets in the trac instance and send a note replying to this thread. More info here: https://fedoraproject.org/wiki/Infrastructure/Meetings#Meetings Thanks kevin

1 1

Mass Password/ssh Key change announcement DRAFT
by Kevin Fenzi 12 Oct '11

12 Oct '11

Greetings. Here's what I have so far on an announcement for the mass password change/ssh key change. Suggestions for improvement very welcome. In particular more resources we could point people to, or common questions you think people will come up with that we could answer would be great. Also, we need to decide what exactly we do to accounts that fail to meet the deadline. Are we just marking them inactive? Do we have any way to force them to change the password and upload a new key if they reactivate the account? kevin -- DRAFT DRAFT DRAFT Subject: IMPORTANT: Manditory password and ssh key change by 2011-11-30 Summary: All existing users of the Fedora Account System (FAS) at https://admin.fedoraproject.org/accounts are required to change their password and upload a NEW ssh public key by 2011-11-30. Failure to do so may result in your account being marked inactive. Backgound and reasoning: This change event has NOT been triggered by any specific compromise or vulnerability in Fedora Infrastructure, rather we feel that due to the large number of high profile sites with security breaches in recent months that this is a great time for all Fedora contributors and users to review their security settings and move to "best practices" on their machines. Additionally, we are putting in place new rules for passwords to increase their entropy and make them less guessable. New Password Rules: * Nine or more characters with lower and upper case letters, digits and punctuation marks. * Ten or more characters with lower and upper case letters and digits. * Twelve or more characters with lower case letters and digits * Twenty or more characters with all lower case letters. * No maximum length. Some Do's and Don'ts: * NEVER store your ssh private key on a shared or public system. * ALWAYS use a strong passphrase on your ssh key. * if you must store passwords, use a application specifically for this purpose like revelation, gnome-keyring, seahorse, or keepassx. * Regularly apply your OSes security related updates. * Only use ssh agent forwarding when needed ( .ssh/config: "ForwardAgent no") * DO verify ssh host keys via dnssec protected dns. ( .ssh/config: "VerifyHostKeyDNS yes") * DO consider a seperate ssh key for Fedora Infrastructure. * Work with and use security features like SELinux and iptables. * Review the Community Standard Infrastructure security document (link below) Q&A: Q: My password and ssh private key are fine and secure! Can't I just skip this change? A: No. We very much hope everyone's password and ssh keys are fine, but we would like everyone to take this chance to review security and change things. In the event of a triggering event everyone will know the process. Q: Can I just change my password and re-upload my same ssh public key? Or upload a bogus ssh public key and then re-upload my old one? A: No. We will be checking to ensure that your ssh public key is different from your old one. Q: This is a hassle. How often is this going to happen? A: The last mass password change in Fedora was more than 3 years ago. Absent a triggering event, these mass changes will be infrequent. More reading: http://infrastructure.fedoraproject.org/csi/security-policy/en-US/html-sing… https://fedoraproject.org/wiki/Infrastructure_mass_password_update

6 15

Re: [Fedora people] - Public key denied
by Jose Manimala 07 Oct '11

07 Oct '11

The output is below, OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to fedorapeople.org [85.236.55.7] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug3: Not a RSA1 key file /home/jose/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /home/jose/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /home/jose/.ssh/id_rsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc(a)lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc(a)lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib(a)openssh.com,zlib debug2: kex_parse_kexinit: none,zlib(a)openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc(a)lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc(a)lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib(a)openssh.com debug2: kex_parse_kexinit: none,zlib(a)openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 126/256 debug2: bits set: 504/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: host fedorapeople.org filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: host fedorapeople.org filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 3 debug3: check_host_in_hostfile: host 85.236.55.7 filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: host 85.236.55.7 filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 4 debug1: Host 'fedorapeople.org' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:3 debug2: bits set: 485/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/jose/.ssh/id_rsa (0x7f87ca789e20) debug1: Authentications that can continue: publickey debug3: start over, passed a different list publickey debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /home/jose/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey). Thanks, Jose Ricky Elrod <codeblock(a)elrod.me> wrote .. > Can you give us the output of: ssh -vvvvv -i /path/to/your/fedora/id_rsa > your_username(a)fedorapeople.org > > -re > > On Fri, Oct 7, 2011 at 12:41 AM, <josemanimala(a)gmail.com> wrote: > > > Hello, > > I tried updating my keys five days ago, and logging into > > fedora people to update my blog feed as the current one lists the whole blog > > and has a lot of irrelevant content in it. I get a public key denied message > > when ever I try to loging to fpeople.o. Can someone help me out with why I > > cant login. Any help is appreciated. > > > > Thank you, > > Jose > > > > _______________________________________________ > > infrastructure mailing list > > infrastructure(a)lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/infrastructure > >

4 8

[Fedora people] - Public key denied
by Jose Manimala 06 Oct '11

06 Oct '11

Hello, I tried updating my keys five days ago, and logging into fedora people to update my blog feed as the current one lists the whole blog and has a lot of irrelevant content in it. I get a public key denied message when ever I try to loging to fpeople.o. Can someone help me out with why I cant login. Any help is appreciated. Thank you, Jose

2 1

Plan for tomorrow's Fedora Infrastructure meeting (2011-10-06)
by Kevin Fenzi 06 Oct '11

06 Oct '11

The infrastructure team will be having it's weekly meeting tomorrow 2011-09-29 at 1900 UTC in #fedora-meeting on the freenode network. Suggested topics (suggested by whom): * New folks introductions and Apprentice tasks. * Password/Ssh-key/Cert reset flag day discussion. * Upcoming Tasks/Items (nirik) ? - swap proxy08 in for proxy01. ? - make a new bastion02/nuke bastion04 ? - move app02/04 2011-10-09 Remove inactive fi-apprentice people. 2011-10-25 - 2011-11-08: Final change freeze 2011-11-01 mail fi-apprentice folks. 2011-11-08: Fedora 16 release. * Meeting tagged tickets: https://fedorahosted.org/fedora-infrastructure/report/10 Submit your agenda items, as tickets in the trac instance and send a note replying to this thread. More info here: https://fedoraproject.org/wiki/Infrastructure/Meetings#Meetings Thanks kevin

1 1

Re: Problem signing FPCA
by Kévin Raymond 06 Oct '11

06 Oct '11

On Thu, Oct 6, 2011 at 5:39 PM, Łukasz Redynk <mr.erdk(a)gmail.com> wrote: > Hello > > Today I've created account on admin.fedoraproject.org and tried to > complete FPCA - but every time I clied link (from my profile home) I saw > 'error 500' - both on Firefox (7.x) and Chrome (15.x). I'd appreciate > any help you can provide to bypass this problem. > > -- > Best regards > Łukasz Redynk Hi, the FAS has more to do with the infra. Infra cced. Regards, -- Kévin Raymond User:shaiton GPG-Key: A5BCB3A2

2 1

FW: serverbeach maint on 2011-10-17
by Kevin Fenzi 05 Oct '11

05 Oct '11

Forwarding on from serverbeach: Please be advised that on October 17th, 2011 between 12:01am ET and ending at 04:00am ET, we will be conducting network maintenance within our Herndon, VA (IAD) Datacenter. This work is being done to combine a small number of our network VLANs into a single, larger VLAN in an effort to make more efficient use of our IPv4 allocations. During the maintenance window you may see up to 20 minutes of network connectivity interruption to these services: 70094 :: serverbeach1 70101 :: serverbeach2 70102 :: serverbeach3 Again this will only briefly affect network connectivity to these services; power to the machines will not be interrupted and they will not be rebooted. This change will result in better utilization of our IPv4 address space at ServerBeach, which will help us continue to provide IPv4 space to our customers far into the future.

1 0

REMINDER: Beta Prerelease Change Freeze
by Kevin Fenzi 05 Oct '11

05 Oct '11

Just a reminder we have now entered into Beta pre-release freeze. Per: http://infrastructure.fedoraproject.org/infra/docs/release-infra.txt All machines/instances in the 'pre release' freeze: https://fedorahosted.org/fedora-infrastructure/browser/architecture/Environ… All changes to these machines require 2 +1's from rel-eng or sysadmin-main after being reviewed on this list. This freeze is over 2011-09-27 (unless Beta slips, then it's over when Beta is released). kevin

1 1

Meeting Agenda Item: Introduction Andrew Smillie
by Andrew Smillie 05 Oct '11

05 Oct '11

Hi, I'm Andrew, a final year computer science student who has been quite active the student run computing facility hosted by GeekSoc [1]. Through this I have gained experience administering CentOS systems set up for a variety of purposes including Joomla and Wordpress on Apache, MySQL, SSH, OpenLDAP, BIND, and NFS. I'll admit that I have a lot to learn about professional system administration - working with a student group providing services to other students is vastly different that a production system used by a *lot* of people - but I am willing to learn and would really like to improve my sysadmin skills. I imagine the best place for me to start would be to poke around the systems a bit to try and better undertand the setup you have and slowly start working on some of the simpler issues. Thanks, Andrew Smillie IRC: Smilers_ (Freenode) FAS: smillie Location: Scotland, UK [1] http://www.geeksoc.org/

3 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure October 2011