Re: Openssl updates
On Saturday 18 November 2006 01:20, Florian La Roche wrote: Interest in Fedora Legacy has slowed down. You can find some FC4 updates at http://www.jur-linux.org/rpms/fc-updates/4/ , but some updates will probably also soon show up at http://fedoralegacy.org/ I can see why this would be the case. I don't want to knock your efforts in any way (very much appreciated!) but the truth is that FL exists to extend the short shelf-life of Fedora. And anything that demands a longer shelf-life I've moved over to CentOS or RHEL. I have but one remaining machine using Fedora as a server (running FC1, in a fairly protected environment) that will be upgraded to CentOS 5 once it's released. FL was more or less born when those who started using Fedora to replace RHL on the servers were bitten by Fedora's short lifespan. (myself included) Even with FL's efforts, the life expectancy is still on the short side... I currently plan against using Fedora in any long-term environment where FL would even be needed... and I'm sure I'm not unique in that! -Ben -- The best way to predict the future is to invent it. - XEROX PARC slogan, circa 1978 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: X-Chat 2.4.0 to 2.6
On Friday 10 March 2006 07:37, Danny Terweij - Net Tuning | Net wrote: That's the mission. You *did* read the mission statement, didn't you? Nope. I dont like reading :P If you don't read the sign that says Caution: Sharks then expect to be bit occasionally. Isn't that what FC4 is supposed to be? Where it ends? FC is not a good choice for production. Linux is stable, linux dont have to reboot much. Linux can run for years without a reboot. If you run a Linux system for years without a reboot on a public network, then your system is likely compromised, and is probably a launching point for crackers, spam relays, DOS attacks, and the like. To securely admin any Linux system all but requires a reboot to start using an updated kernel at the very least every few months or so, and frequently more often than that. I do not want to upgrade my production machines every 6 months because FC has a new version. Then use CentOS if you like RedHat, or try Debian, Gentoo, or something else. Those new versions holds new versions of software. Why cant they build one FC and update/upgrade just the installed versions? Because, then, it wouldn't be the same release anymore? Perhaps I'm mistaken, but questions like these indicate (to me) that you just want others to solve your problems for free. You think every user reading that? Here a practical user example: - Hmm no more updates when i do yum update - lets google - hey a new repo called legacy.. - Ah here i found how to add it to my yum - Nice i get updates again But actualy it are not updates, but fixes/patches. But they *are* updates. They are *security* updates, so that systems that are otherwise stable don't have to be retired or messed with to keep working. New versions would destabilize such systems. If you want *new* versions, then get a *new* operating system version. -After some time, he finds out that newer versions are not delivered. -Finds alternate repos like atrpms dag dries livna etc... -doing yum update, oh look again new versions :) This is a real example how most of the linux users are doing without read any statement text. Because its not intresting to read :) sed -e s/'most of the linux users'/'me'/g; But you wouldn't read up to find out what that does either, would you? -Ben -- I kept looking around for somebody to solve the problem. Then I realized I am somebody -Anonymous -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: X-Chat 2.4.0 to 2.6
On Friday 10 March 2006 07:37, Danny Terweij - Net Tuning | Net wrote: That's the mission. You *did* read the mission statement, didn't you? Nope. I dont like reading :P If you don't read the sign that says Caution: Sharks then expect to be bit occasionally. Isn't that what FC4 is supposed to be? Where it ends? FC is not a good choice for production. Linux is stable, linux dont have to reboot much. Linux can run for years without a reboot. If you run a Linux system for years without a reboot on a public network, then your system is likely compromised, and is probably a launching point for crackers, spam relays, DOS attacks, and the like. To securely admin any Linux system all but requires a reboot to start using an updated kernel at the very least every few months or so, and frequently more often than that. I do not want to upgrade my production machines every 6 months because FC has a new version. Then use CentOS if you like RedHat, or try Debian, Gentoo, or something else. Those new versions holds new versions of software. Why cant they build one FC and update/upgrade just the installed versions? Because, then, it wouldn't be the same release anymore? Perhaps I'm mistaken, but questions like these indicate (to me) that you just want others to solve your problems for free. You think every user reading that? Here a practical user example: - Hmm no more updates when i do yum update - lets google - hey a new repo called legacy.. - Ah here i found how to add it to my yum - Nice i get updates again But actualy it are not updates, but fixes/patches. But they *are* updates. They are *security* updates, so that systems that are otherwise stable don't have to be retired or messed with to keep working. New versions would destabilize such systems. If you want *new* versions, then get a *new* operating system version. -After some time, he finds out that newer versions are not delivered. -Finds alternate repos like atrpms dag dries livna etc... -doing yum update, oh look again new versions :) This is a real example how most of the linux users are doing without read any statement text. Because its not intresting to read :) sed -e s/'most of the linux users'/'me'/g; But you wouldn't read up to find out what that does either, would you? -Ben -- I kept looking around for somebody to solve the problem. Then I realized I am somebody -Anonymous -- The best way to predict the future is to invent it. - XEROX PARC slogan, circa 1978 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: The actual proposed QA changes - getting on same page
I like this proposed change. -Ben On Tuesday 14 February 2006 14:55, David Eisenstein wrote: Here below is my understanding of what has been proposed and (correct me if I am wrong) appear to be in the process of being implemented. Fedora Legacy QA Process Overview w/Proposed Changes 1. Vulnerability discerned. 2. Bugzilla ticket for package and vulnerability (with CVE #) opened. 3. Source package(s) for vulnerability proposed. 4. People do SOURCE LEVEL (PUBLISH) QA on the packages and report in Bugzilla their findings. 5. Once all source packages have been voted for PUBLISH, new signed packages are built and both .src.rpm and (.i386|.x86_64).rpm packages are pushed to updates-testing. An announcement goes out to fedora-legacy-list announcing that packages are ready for testing and asking for participation in doing VERIFY QA. NOTE: If there are any objections in the PUBLISH QA or if any distro does not receive a PUBLISH vote, nothing further is done with that package until the issue(s) are resolved. Old Policy - VERIFY QA to RELEASE: 6. If no positive votes happen on binary packages in updates-testing, they stay in updates-testing and go no further. 7. If one positive vote happens on one distro for pkgs. in updates- testing, a 4-week timeout is set. If no further votes happen before timeout, then after 4 weeks, all packages are released to updates. 8. If two or more distro's (but less than all distros) have positive votes, the 4-week timeout is reduced to a two-week timeout at the time the 2nd distro has a + vote. At timeout, all packages are released to updates. 9. If all distros get + votes, binary packages are considered fully tested, and can be released to updates straight away. New (Proposed Policy) - VERIFY QA to RELEASE: 6. If no positive votes happen on binary packages in updates-testing, they will be released after a 2-week timeout after having placed in updates-testing. 7. If one positive vote happens on one distro for the pkgs. in updates- testing, the 2-week timeout is reduced to 1-week from the point of the first positive vote. 8. If two or more distro's (but less than all distros) have positive votes, the same timeout in step (7) of the new policy applies. 9. As in the old policy, if all distros get + votes, binary pack- ages are considered fully tested and can be released to updates right away. Both policies: 10. Packages released to updates from updates-testing are announced on fedora-legacy-list and fedora-legacy-announce-list. -David -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- I kept looking around for somebody to solve the problem. Then I realized I am somebody -Anonymous -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing]
On Sunday 12 February 2006 12:17, Pekka Savola wrote: Hi, It seems there's rather strong agreement for this. Yep. (From me) Unless I hear major objections in two days, I'll start the two-week clock (from today) for all the pending packages. Cool! After that I'll also update the Wiki entry for QaVerify unless someone else has done it. On Sat, 11 Feb 2006, Marc Deslauriers wrote: I have proposed something simpler, and still do: 1) every package, even without any VERIFY QA votes at all, will be released automatically in X weeks (suggest: X=2). exception: at package PUBLISH time, the packager and/or publisher, if they think the changes are major enough (e.g., non-QAed patches etc.), they can specify that the package should not be automatically released. 2) negative reports block automatic publishing. 3) positive reports can speed up automatic publishing (for example: 2 VERIFY votes -- released within 1 week, all verify votes: released immediately after the last verify) There is no need (IMHO) to grade packages to more or less critical ones. Every QA tester and eventual package user uses his or her own value judgment. If (s)he fears that the (potentially untested) automatic update would break the system, (s)he would test it before two weeks are over. Publishing positive reports can be made simpler but that probably isn't on the critical path here. I agree to this. Marc -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- I kept looking around for somebody to solve the problem. Then I realized I am somebody -Anonymous -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: no mandatory QA testing at all [Re: crazy thought about how to ease QA testing]
On Friday 10 February 2006 21:32, Pekka Savola wrote: On Fri, 10 Feb 2006, Jesse Keating wrote: This makes it even more complicated. points? how many are enough? What makes one package more critical than another? How ambiguous could this be? I agree that this would complicate the process further. I have proposed something simpler, and still do: 1) every package, even without any VERIFY QA votes at all, will be released automatically in X weeks (suggest: X=2). exception: at package PUBLISH time, the packager and/or publisher, if they think the changes are major enough (e.g., non-QAed patches etc.), they can specify that the package should not be automatically released. 2) negative reports block automatic publishing. 3) positive reports can speed up automatic publishing (for example: 2 VERIFY votes -- released within 1 week, all verify votes: released immediately after the last verify) Pekka, I've proposed (1, 2) before... That's why I've moved my last remaining FC1 systems to testing - I've just not had problems with the updates, and I'd rather run a secure but occasionally unstable system than an insecure but stable one. Oh, and I've had ZERO problems with stability... -Ben -- The best way to predict the future is to invent it. - XEROX PARC slogan, circa 1978 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: issues list(s)
The process of QA testing is a pain, and fraught with potential errors. I see no reason why this should be - two members of this list have come up with a good foundation for scripts that automate much of the process of determining test packages that are installed. Both parties (myself being one of them) have expressed strong interest in working with the FL website maintainers to make submitting this information easy, painless, and relatively error-free. In short, give us a URI template that we can write a script to go to in order to report packages that are in test that are installed, and we'll happily make it easy to setup/use. Making it easier to do will result in more people doing it! Whattaya say? -Ben On Saturday 04 February 2006 14:48, Pekka Savola wrote: Remember, there's always a need for folks to do some QA testing. See the wiki for instructions and how to get started: http://www.fedoraproject.org/wiki/Legacy/QATesting Personally, I'd like to get special attention at: - there's gaim, squid, mod_auth_pgsql, and auth_ldap sitting at VERIFY pile. Especially if you use any of the last three, PLEASE report success/failure. - I'd like to pinpoint folks to the recent two critical mozilla vulns, which I filed as #180036 See the full lists at: http://www.netcore.fi/pekkas/buglist.html (all) http://www.netcore.fi/pekkas/buglist-rhl73.html http://www.netcore.fi/pekkas/buglist-rhl9.html http://www.netcore.fi/pekkas/buglist-core1.html http://www.netcore.fi/pekkas/buglist-fc2.html http://www.netcore.fi/pekkas/buglist-fc3.html -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- The best way to predict the future is to invent it. - XEROX PARC slogan, circa 1978 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Auto-reporting of successful testing packages
Well, I finally did it. Attached is a PHP script that, when run at the command line, returns a list of testing packages currently installed. Thus, doing some basic testing of packages can be boiled down to: 1) Setup yum to access updates-testing repo. 2) yum -y update; 3) Wait a day or three for anything to break; 4) When all looks well, run get_testing_rpms_installed.php 5) Report the packages. I'll do some poking around here; it may be possible to have basic OKs submitted automatically. -Ben -- The best way to predict the future is to invent it. - XEROX PARC slogan, circa 1978 get_testing_rpms_installed.php Description: application/php -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Fedora Updates testing
How many updates from FL have been rejected due to bugs or things not working? I updated my FC1 yum.conf to include testing, and I've not noticed anything unusual. (Wish I had the time to figure out how to test, let alone do the testing...) -Ben -- The best way to predict the future is to invent it. - XEROX PARC slogan, circa 1978 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Re: Another security problem..
Some time ago, I wrote a program in PHP that ran as a background task, essentially grabbing the stdin from a tail -f /var/log/httpd/access.log It would scan each line of the input for certain patterns. EG: a certain # of hits in the most recent 5 minutes, a bunch of others like known sploits and similar behavior (such as wget in the URL) and instantly add the offenders to iptables reject for 24 hours. Worked fairly well, but eventually I found maintaining the pattern list cumbersome, and the test types were somewhat difficult to genericize into a config file. Also, caused problems with NAT'd companies, where 1 dirtbag would kick the whole place out for 24 hours. Perhaps this should be released as an OSS Project somewhere? Maybe there's already something out there? Dunno. Quick hack, solved a problem I was having at the time, now dead wood and I might not even have it around, anymore. -Ben On Thursday 20 October 2005 12:38, Matthew Nuzum wrote: I've not looked into it, but it would be nice if there was some *simple* to maintain script that would detect these types of probes and automatically add the IP to hosts.deny and etc. -- Matthew Nuzum [EMAIL PROTECTED] www.followers.net - Makers of Elite Content Management System View samples of Elite CMS in action by visiting http://www.followers.net/portfolio/ -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list -- The best way to predict the future is to invent it. - XEROX PARC slogan, circa 1978 -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
Dumb Question
I'd like to get check out updates that have not been approved. How do I set up the yum.conf on my FC1 system to get these updates? -Ben -- I kept looking around for somebody to solve the problem. Then I realized I am somebody -Anonymous -- fedora-legacy-list mailing list fedora-legacy-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legacy-list
