Mark, Thanks again - I will attempt to finish the updates and see if that fixes the problem. What is so weird to me is that I can use it just fine and so can other people. So far it is only two people on campus that cannot. If I go into /etc/passwd and change him from /opt/openssh/libexec/sftp-server to /usr/openssh/libexec/sftp-server then he gets a different error message. With the 1st path - he gets 'There's no site named 'faculty-staff/jadams' But with the 2nd path - he gets "FTP transmits the user name and password without encryption. If possible, open the site by using an HTTP URL to help protect it from potential network attacks." The funny thing is we are not using FTP - we use sftp and I've tried logging in as him on from with expression web and get the same. Any thoughts? Also, thank you for the book references. Constance -----Original Message----- From: redhat-list-bounces@xxxxxxxxxx [mailto:redhat-list-bounces@xxxxxxxxxx] On Behalf Of m.roth@xxxxxxxxx Sent: Thursday, May 02, 2013 9:46 AM To: General Red Hat Linux discussion list Subject: RE: [redhat-list] sftp error question Hi, Constance, Constance Morris wrote: > <snip> >> (This would have to do with the apache configuration (httpd); that's >> in /etc/httpd/conf and /etc/httpd/conf.d Sounds to me as though the >> virtual hosts are messed up, or possibly that you have secondary IPs, >> for which you need to look at /etc/sysconfig/network-scripts.) > > I've checked the httpd files (conf and conf.d) but they have not been > updated by the updates that took place thus far. But in Updates will *not* overwrite existing configuration files, esp. if they've been changed from what came in the original release - you'll see they dump the new versions as *.rpmnew. > /etc/sysconfig/network-scripts I can see 3 that were updated (ifdown, > ifdown-isdn, ifup, ifup-isdn). That may well be ok. I suspect you're not using ISDN, and ifdown is a shutdown the network script, with no effect on bringing it up. > >> (What I did at work, several years ago, was to talk to the system >> owners, and set up a regular monthly maintenance window, when I could >> do full updates - bug and security fixes - and reboot as needed. And >> they make sure their users know of the window.) > > Unfortunately, I do not have that luxury. So I have to do them in > between semester breaks....etc. <g> There are holidays... but you can do updates, and that won't really affect anyone until the program's restarted. There *are* certain provisos to that, though, things like glibc (the C libraries that everything uses). If you need to do something, I recommend, in this order, Tuesday or Thursday morning somewhere between 02:00 and 06:00. (This is based on personal knowledge that the City of Chicago 911 system, when they do maintenance, that's the least-busy time). You certainly wouldn't need more than half an hour... WITH THE EXCEPTION of fsck. That, you can certainly do between semesters - twice a year is fine. > >> (Third, if this is a server, and *esp* if it's a production machine, >> I would recommend turning off yum-updatesd (that's the auto-updated; >> it doesn't exist in 6.x) - you should consider the updates, and >> coordinate if there's something that your users might see, like NFS >> or apache, etc.) > >> Thank you - I will turn that off as it is a production server. What >> did you mean by: " you should consider the updates, and coordinate if >> there's something that your users might see, like NFS or apache, >> etc"? I assume you meant, being careful what updates I do and when I >> do them, but I wasn't sure. Yep. There are things that would affect a lot of folks - websites, for example, and restarting things like apache, or if (as I hope) you've got NFS-mounted home directories. For the latter, you *have* to have users log out and log back in, or they're immediately start getting the dreaded "Stale File Handle" error. A recommendation: if you're going to be doing this for a while, you should pick up one of two books, and READ IT ALL THE WAY THROUGH: either Frisch's Essential Systems Administration, published by O'Reilly*, or Nemeth, Snyder, Seebass & Hein's Unix Systems Administration Handbook, published by Prentice Hall. These are the two books that just about all sysadmins know. Yeah, the Frisch one's about 10 years since the last update, but at the very least, find it, and read chapter 2: The Unix Way, which will give you full Enlightenment about how all version of *Nix work, and the architecture that underpins them. > > Thank you for responding Mark! That's why we hang out on lists like this, to help each other. * Almost any book published by O'Reilly is *good* - almost all computer folks I know have anywhere from one book from them to a shelf of them. They're the only publisher I know that goes out of their way to not only find people who *really* know their subject, but can actually *communicate* that information. mark > > Constance > > -----Original Message----- > From: redhat-list-bounces@xxxxxxxxxx > [mailto:redhat-list-bounces@xxxxxxxxxx] On Behalf Of mark > Sent: Thursday, May 02, 2013 8:06 AM > To: General Red Hat Linux discussion list > Subject: Re: [redhat-list] sftp error question > > On 05/02/13 07:35, Constance Morris wrote: >> Hi everyone, I'm new to this list, so I apologize if my email is not >> in keeping with the procedures. I am a newbie with RHEL 5.7 system >> administration and recently registered our web server with Red Hat >> (this past Monday). Upon registration, I noticed online that the >> server needed >> 506 updates and so I set the auto errata to enabled. By the time, I >> realized my mistake there were only 217 updates left to be done. I >> changed the auto errata to disabled and locked the account to stop >> the rest from going through on their own. > > Hi, Constance, > > You've probably got several things going on. > > First, finish the full updates, really. 5.7 is several years old - > it's now on 5.9, for the 5.x branch (the 6.x is up to 6.4 as of > several months > ago) and if you type lsb_release -a, that's what you should see. > Having it partly updated is asking for trouble, esp. if interrelated > packages are not all installed, such as an application like apache, > but libraries it needs aren't updated. > > Second, when you do a reboot, it *will* have major issues, unless you > finish that update, for the reason above. > > Third, if this is a server, and *esp* if it's a production machine, I > would recommend turning off yum-updatesd (that's the auto-updated; it > doesn't exist in 6.x) - you should consider the updates, and > coordinate if there's something that your users might see, like NFS or apache, etc. >> >> Immediately following, I was unable to use Putty to ssh to the web >> server. A co-worker worked with me to get us access again by updating >> the > > And, presumably, restarting sshd (service sshd restart). > >> sshd_config file. However, we have some clients who use Expression >> Web >> 4 to update sites and they cannot gain access. It says "There's no >> site named 'blah' " when they try to login. > > This would have to do with the apache configuration (httpd); that's in > /etc/httpd/conf and /etc/httpd/conf.d Sounds to me as though the > virtual hosts are messed up, or possibly that you have secondary IPs, > for which you need to look at /etc/sysconfig/network-scripts. > > *Do* run yum update regularly. RH should be emailing you about > updates; anything labelled "critical" (like firefox) should be done > that day; important, if you read what it fixes and find that it > affects you, in the next couple of days. What I did at work, several > years ago, was to talk to the system owners, and set up a regular > monthly maintenance window, when I could do full updates - bug and > security fixes - and reboot as needed. And they make sure their users know of the window. > > mark > > -- > redhat-list mailing list > unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/redhat-list > > -- > redhat-list mailing list > unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/redhat-list > -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
