Re: LAN Card doesn't activate
2010/1/8 j.halifax . j.hali...@seznam.cz: Doesn't anybody know why my LAN Cards don't get active after rebooting despite of having the check-box for automated activation checked? After every reboot I have to open Network option in System-Admin menu and activate cards manual way. Take a look at the file /etc/sysconfig/network-scripts/ifcfg-eth0 or equivalent. There should be a line in there that reads ONBOOT=yes. If you are using profiles, then you'll need to look under /etc/sysconfig/networking/profiles/ as well. -- Andy The only person to have all his work done by Friday was Robinson Crusoe -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Recover Root Password on FC 11 and Missing GRUB Screen
Adding to what Marko wrote, since it sounds from the original post like the system may be configured to ask for a password in single user mode. If that's the case you'll need to boot from the Fedora install disc and choose the rescue mode, or if not available use any Linux rescue/recovery disk and mount the root partition manually. Once that's done, *carefully* edit the file /etc/shadow on the system's boot disk and delete the long string of gibberish between root: and the next :, the next time you boot in single user mode it will drop you directly to the root prompt without a login and you can then use password to enter a new password. If it comes to this and you have the HDD's /etc actually mounted on /etc, then if at all possible use the command vipw -s to edit the file as this will set the necessary locks to prevent any file corruption etc. -- Andy The only person to have all his work done by Friday was Robinson Crusoe -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: 36 or 64 bit?
I'd boot the 32bit LiveCD version and if it sorts your problems out, then go ahead and install it, at least until you know your issues with the 64bit version are fixed. The idea that 64bit performs better than 32bit is a bit of a fallacy anyway. There are some advantages, but generally they only come into play when dealing with more than 2GB of mapped memory, doing lots of math or manipulating large chunks of data that can be processed 64 bits at a time instead of 32. For a general purpose desktop or laptop, you'll probably not really notice much benefit most of the time and the executables are all slightly larger too. -- Andy The only person to have all his work done by Friday was Robinson Crusoe -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: gmail endless redirecting
In addition to the above suggestions you could also try disabling Google Labs by using the following URL: http://mail.google.com/mail/?labs=0 If that improves stability, then switch off any Labs features you are using then turn them back on one by one until you identify the culprit. Failing that, flushing the browser cache and deleting any Google cookies has always fixed GMail issues for me, regardless of what browser/platform I was using. -- Andy The only person to have all his work done by Friday was Robinson Crusoe -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: rkhunter warning after updating
2009/12/2 Bill Davidsen david...@tmr.com: Wow, a list of things I really don't want to change and an evil doer might like to change. Whitelisting is kind of like taking the battery out of the smoke detector, it stops the noise but loses the warning. Short term I'd rather manually verify the checksums of the new packages, and long term, if Kevin doesn't push a new list, you can build it yourself. I agree entirely. That's why I've got mine configured to ignore just the specific versions of the applications that I have currently installed that RKHunter complains about - if the version changes, RKHunter will complain and I'll know about it. Of course, to tamper with the RKHunter files as installed by the package an attacker would already need to be root so I'm not too concerned about that aspect, and I run rpm --checksig on all new or updated packages before installation anyway. However, Kevin made some valid points about managing the version number updates, even though we're only talking about nine applications here. I had a look into the mechanism used by RKHunter last night with a view to checking other applications, and it's something of a dog to say the least, so I can understand why Kevin didn't really want to touch it. Essentially there are two ASCII files in /var/lib/rkhunter/db/, programs_bad.dat and programs_good.dat, that contain lists of known bad and good application versions respectively for each application being checked and, as you might imagine, some of those lists are rather long... It was RKHunter's downloading of an updated version of programs_bad.dat during its initialisation update check that caused the warnings over the weekend, so simply amending the dat file isn't a solution unless you also ensure it that won't get overwritten by RKHunter's update mechanism. How to best prevent similar false alarms in future without requiring end-user involvement, I don't know. The only approaches I can think of are to disable the apps test, which Kevin suggested, or to watch testing for new updates to the checked applications then proactively update the whitelist in rkhunter.conf and push an updated RKHunter package. An easier option might be to update the remote version of programs_bad.dat file, but I'm assuming that is outside of Fedora's control since it wasn't the only distro to experience the problem. -- Andy The only person to have all his work done by Friday was Robinson Crusoe -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: rkhunter warning after updating
2009/11/30 Kevin Fenzi ke...@scrye.com: Disable the application checks. I am going to likely push out a new rkhunter package that does this soon. The problem is that upstream pushes out a dat file with the versions of those packages that are up to date and proof against known security issues. Fedora often backports fixes for stable releases, so the version isn't very good as an indicator when you are safe or not. I'm not sure that disabling the application checks is the best approach. There is a mechanism in rkhunter.conf to whitelist specific applications (APP_WHITELIST), either by name or name and version. I'd rather know about it when things change, so I've put the version numbers in as well since it's a quick update if and when Fedora updates the release instead of back-porting patches. The line in my rkhunter.conf on F11 is as follows: APP_WHITELIST=gpg:1.4.0 httpd:2.2.13 named:9.6.1 sshd:5.2p1 You'd need to adapt the version numbers per Fedora release of course (or forego them entirely) but IMHO it's still preferable to disabling the application checks entirely. -- Andy The only person to have all his work done by Friday was Robinson Crusoe -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: rkhunter warning after updating
2009/11/30 Kevin Fenzi ke...@scrye.com: Sure, that works fine if you are willing to keep up to date on security updates on those applications and update your config each time one changes in fedora. I did say that I like to know when things change, hence the inclusion of the version numbers. That approach also works very well if you need to keep a package at a certain revision for some reason as including its specific version in rkhunter.conf would provide a warning should an update ever be applied by mistake, or a default package be installed instead of a custom build for that matter. That's definitely not appropriate for a dynamic distribution like Fedora, although maybe something like Debian Stable or Red Hat where version numbers don't change much could get away with it. For the out of box package that would result in pushing an update to rkhunter anytime any of those updated and there could be lag between the updates and when someone applied the rkhunter one. That's a good point about the lag and it would be a problem, but then again it wouldn't be the only package in Fedora that needed to be updated in response to changes to another, apparently unrelated one; Yelp and Firefox for instance. For a more general package distribution it would definitely be better to either disable the checks or just push the RKHunter package with a whitelist of problematic applications without the version numbers, for instance: APP_WHITELIST=gpg httpd named sshd... I don't think it would actually be that hard to manage the list as RKHunter currently only check the versions of nine key packages - presumably to the author of RKHunter since Exim and ProFTP are checked while Fedora's defaults of Sendmail and VSFTP are not. All that would be required would be to monitor Fedora testing for version number changes to the tested packages and proactively push a new version of the RKHunter package with an updated config before the move to updates. But sure, if you want to maintain a list locally, feel free. Well, since I'm not the Fedora RKHunter packager, that's one of the benefits of Open Source that I might be taking advantage off - the other being to poke around in the source and figure out how to test the versions of some other applications. :) -- Andy The only person to have all his work done by Friday was Robinson Crusoe -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
