April 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305491] package names should also be binary names
by fate_noreply＠suse.de 20 Apr '09

20 Apr '09

Feature changed by: Kai Dupke (kdupke) Feature #305491, revision 35 Title: package names should also be binary names openSUSE-11.2: Duplicate of #303730 Priority Requester: Desirable Requested by: Juergen Weigert (jnweiger) Description: Many packages providing command line applications do so with commands named different than the package Random examples: install cpuset but call cset; install lvm2 but call lvm; install MPlayer but call mplayer, install MozillaFirefox but call firefox, install NetworkManager-kde but call knetworkmanager; install OpenOffice_org but call soffice/ooffice/oowriter I suggest to create one shell script per package, that is named exactly as the package is named, which tells the user how to use the package (unless a binary with that name already exists). This script could point to existing binaries, print documentation, or simply be a symlink to an existing binary if there is one prominent user callable entry point, whatever makes sense. Discussion: #2: Thorsten Kukuk (kukuk) (2008-11-25 05:58:17) Veto. We decided to name RPMs after the name of the upstream package, especially to be in sync with other distributions and don't confuse ISVs and customers completlty. I don't see any benefit for customers, but only disadvantages for everybody. Between, business case for this very cost-intensiv feature is missing. #3: Thorsten Kukuk (kukuk) (2008-11-25 05:59:18) How would you call "pwdutils"? "useradd"? "userdel"? "passwd"? Split them in 100 little RPMs? #10: Thomas Schmidt (digitaltomm) (2008-11-26 12:00:29) This could be added to the command-not-found tool (http://en.opensuse.org/Scout , don't know whether this is available on SLES). When a command is not found, but scout sees a RPM with exactly this name installed it could display a list of the included binaries. This way no packages would need to be changed, it's only an enhancement to command-not-found. #11: Kai Dupke (kdupke) (2008-11-26 12:43:29) (reply to #10) scout is part of the SLES media. Looks like an answer on how to handle this. Not sure if we install this by default. #14: Pavol Rusnak (prusnak) (2009-01-09 15:56:02) (reply to #11) I and mvyskocil are creators and maintainers of scout. All you need to do is to issue (after installing scout of course): $ scout bin firefox repository | binary | path | package --------------------+---------+----------+---------------- zypp (11.1-oss) | firefox | /usr/bin | MozillaFirefox What else needs to be done? #16: Pavol Rusnak (prusnak) (2009-01-09 15:57:33) (reply to #14) I forgot to note that scout is automatically installed in base system in openSUSE 11.1. #17: Juergen Weigert (jnweiger) (2009-01-09 16:43:41) (reply to #11) Hey, thanks for creating scout. This is very helpful. Currently, I can map from binary to package, by using 'scout bin' This feature is about the reverse, mapping from package to binary. Can this be added to scout? Integration with /usr/bin/command-not-found would be very helpful then. E.g. bash$ MPlayer Package MPlayer includes the following binaries: repository | binary | path | package ---------------------------+---------+----------+--------- zypp (Packman Repository) | mplayer | /usr/bin | MPlayer How do we educate our users about the existance of scout? #19: Pavol Rusnak (prusnak) (2009-01-09 17:30:10) (reply to #17) After discussion with Michal, we'll add -p parameter to each module, which will indicate that package name is provided, not search_term. All modules will benefit from that change, not only "bin", so user could also list all java classes from java package and so on. I'm not quite sure about the command-not-found integration. There are some people who don't like the speed of handler and another extra search will add another fractions of seconds. If user wants that feature, he'll just types: $ scout bin -p MPlayer #20: Pavol Rusnak (prusnak) (2009-01-12 17:58:19) (reply to #19) I pushed change into scout git repo which adds -p option to all modules. Updated packages are also available from home:prusnak:scout repository. Feel free to test. $ scout bin mplayer repository | package | path | binary ----------------+---------+----------+--------- zypp (packman) | MPlayer | /usr/bin | mplayer $ scout bin -p MPlayer repository | package | path | binary ----------------+---------+----------+---------- zypp (packman) | MPlayer | /usr/bin | mplayer zypp (packman) | MPlayer | /usr/bin | gmplayer zypp (packman) | MPlayer | /usr/bin | mencvcd zypp (packman) | MPlayer | /usr/bin | mencoder #15: Michael Loeffler (sprudel24) (2009-01-09 15:58:57) (reply to #10) The Scout way sounds like a good solution. #21: Federico Lucifredi (flucifredi) (2009-01-23 15:18:04) Wow. What a discussion. Stano, we spoke with Michal last year about adopting someone's Hack Week work to provide hinting just the way Ubuntu does (when typing a command name that is not in the system, suggest " zypper in [packagename]" with the appropriate package. This is a duplicate of another feature, and something already agreed on. Package renaming seems unlikely, but hinting was in the list since 11.0. Stano, can you please give us the status on that, and close this feature as duplicate if you can find the other ? #23: Kyle Agronick (metal_head_3767) (2009-04-18 07:57:29) Why not just keep the packages the same but show the executable name in software managment? Also have an option to search by the executable name. + #24: Kai Dupke (kdupke) (2009-04-20 08:10:39) (reply to #23) + I support this idea. However if I'm right then the file list (needed + for the executable searc) is only available after installing a package. + Else we would need to have more data in the meta data which I have some + concerns that the effort is really balanced towards the benefit. -- openSUSE Feature: https://features.opensuse.org/305491

1 0

[openFATE 305491] package names should also be binary names
by fate_noreply＠suse.de 18 Apr '09

18 Apr '09

Feature changed by: Kyle Agronick (metal_head_3767) Feature #305491, revision 34 Title: package names should also be binary names openSUSE-11.2: Duplicate of #303730 Priority Requester: Desirable Requested by: Juergen Weigert (jnweiger) Description: Many packages providing command line applications do so with commands named different than the package Random examples: install cpuset but call cset; install lvm2 but call lvm; install MPlayer but call mplayer, install MozillaFirefox but call firefox, install NetworkManager-kde but call knetworkmanager; install OpenOffice_org but call soffice/ooffice/oowriter I suggest to create one shell script per package, that is named exactly as the package is named, which tells the user how to use the package (unless a binary with that name already exists). This script could point to existing binaries, print documentation, or simply be a symlink to an existing binary if there is one prominent user callable entry point, whatever makes sense. Discussion: #2: Thorsten Kukuk (kukuk) (2008-11-25 05:58:17) Veto. We decided to name RPMs after the name of the upstream package, especially to be in sync with other distributions and don't confuse ISVs and customers completlty. I don't see any benefit for customers, but only disadvantages for everybody. Between, business case for this very cost-intensiv feature is missing. #3: Thorsten Kukuk (kukuk) (2008-11-25 05:59:18) How would you call "pwdutils"? "useradd"? "userdel"? "passwd"? Split them in 100 little RPMs? #10: Thomas Schmidt (digitaltomm) (2008-11-26 12:00:29) This could be added to the command-not-found tool (http://en.opensuse.org/Scout , don't know whether this is available on SLES). When a command is not found, but scout sees a RPM with exactly this name installed it could display a list of the included binaries. This way no packages would need to be changed, it's only an enhancement to command-not-found. #11: Kai Dupke (kdupke) (2008-11-26 12:43:29) (reply to #10) scout is part of the SLES media. Looks like an answer on how to handle this. Not sure if we install this by default. #14: Pavol Rusnak (prusnak) (2009-01-09 15:56:02) (reply to #11) I and mvyskocil are creators and maintainers of scout. All you need to do is to issue (after installing scout of course): $ scout bin firefox repository | binary | path | package --------------------+---------+----------+---------------- zypp (11.1-oss) | firefox | /usr/bin | MozillaFirefox What else needs to be done? #16: Pavol Rusnak (prusnak) (2009-01-09 15:57:33) (reply to #14) I forgot to note that scout is automatically installed in base system in openSUSE 11.1. #17: Juergen Weigert (jnweiger) (2009-01-09 16:43:41) (reply to #11) Hey, thanks for creating scout. This is very helpful. Currently, I can map from binary to package, by using 'scout bin' This feature is about the reverse, mapping from package to binary. Can this be added to scout? Integration with /usr/bin/command-not-found would be very helpful then. E.g. bash$ MPlayer Package MPlayer includes the following binaries: repository | binary | path | package ---------------------------+---------+----------+--------- zypp (Packman Repository) | mplayer | /usr/bin | MPlayer How do we educate our users about the existance of scout? #19: Pavol Rusnak (prusnak) (2009-01-09 17:30:10) (reply to #17) After discussion with Michal, we'll add -p parameter to each module, which will indicate that package name is provided, not search_term. All modules will benefit from that change, not only "bin", so user could also list all java classes from java package and so on. I'm not quite sure about the command-not-found integration. There are some people who don't like the speed of handler and another extra search will add another fractions of seconds. If user wants that feature, he'll just types: $ scout bin -p MPlayer #20: Pavol Rusnak (prusnak) (2009-01-12 17:58:19) (reply to #19) I pushed change into scout git repo which adds -p option to all modules. Updated packages are also available from home:prusnak:scout repository. Feel free to test. $ scout bin mplayer repository | package | path | binary ----------------+---------+----------+--------- zypp (packman) | MPlayer | /usr/bin | mplayer $ scout bin -p MPlayer repository | package | path | binary ----------------+---------+----------+---------- zypp (packman) | MPlayer | /usr/bin | mplayer zypp (packman) | MPlayer | /usr/bin | gmplayer zypp (packman) | MPlayer | /usr/bin | mencvcd zypp (packman) | MPlayer | /usr/bin | mencoder #15: Michael Loeffler (sprudel24) (2009-01-09 15:58:57) (reply to #10) The Scout way sounds like a good solution. #21: Federico Lucifredi (flucifredi) (2009-01-23 15:18:04) Wow. What a discussion. Stano, we spoke with Michal last year about adopting someone's Hack Week work to provide hinting just the way Ubuntu does (when typing a command name that is not in the system, suggest " zypper in [packagename]" with the appropriate package. This is a duplicate of another feature, and something already agreed on. Package renaming seems unlikely, but hinting was in the list since 11.0. Stano, can you please give us the status on that, and close this feature as duplicate if you can find the other ? + #23: Kyle Agronick (metal_head_3767) (2009-04-18 07:57:29) + Why not just keep the packages the same but show the executable name in + software managment? Also have an option to search by the executable + name. + -- openSUSE Feature: https://features.opensuse.org/305491

1 0

[openFATE 305296] Easy Way to Disable Beagle Completely During Installation
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature changed by: john andersen (jsamyth) Feature #305296, revision 72 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #26: Peter Nixon (peternixon) (2009-03-11 20:39:01) (reply to #3) +1 #29: Pedro Veloso (pedrodh) (2009-04-01 22:18:05) (reply to #26) Totally agree #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. #12: Bart Otten (bartotten) (2009-02-16 01:13:58) I agree with the people voting to disable it by default. I think we have to keep focus on the 'consumer' and most of them won't use Kerry/Beagle. ps. KDE4 -and- Beagle is useless. KDE4 uses Strigi and Nepomuk. #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) Despite all who now have voted for this proposal, I just have to vote against it. At least in the forms discussed here. I use Beagle heavily as do some other people I got convinced to use openSUSE instead of Windows. A good Desktop search was among the arguments to move these people to change their OS (others arguments were Deskbar etc... which btw. does not necessarily need Beagle but gets some interesting advantages IF Beagle is activated). Why not simply ask at startup how to configure some basic system defaults. Among them there could be beagle. So concerning the proposals of Federico Lucifredi, Stephan Kulow and so on, I am definitively of the same mind. Beagle should be installed by default, but it should be easy to switch it "on" or "off" whenever one wants. #14: Eric Springer (erikina) (2009-02-18 01:05:18) (reply to #13) Yes, a search is very useful. Yes, some people find beagle beneficial (as apparently you do). But the vast majority (Currently the vote is at 47:1) of people it doesn't work well with. And that's truly an amazing statistic, as it's super easy to see and use the feature it provides but much harder to see that it's beagle causing so many (resource related) problems. And if that statistic alone isn't enough to convince you it's not a sensible default, then I have absolutely no idea how to. There really should be a resemblance of QA in place, especially for default (and completely optional) packages. #15: Sebastian Rösgen (palimpseste) (2009-02-19 12:04:23) (reply to #14) Ok, I hope that my comment did not sound as gruff or ... brusque, for I, basically, hoped to present a different opinion. What I did not intend was to, evidently, irritate somebody by not completely assenting to his opinion. See: I am working for a university in Germany. We have 45.000 students and a staff of employees of a size appropriate for this amount of students. We rely heavily on the capabilities of a search system (to be honest: in this case not beagle, but somethings similar to beagle). I am one person who posts here but, to stay in your line of argumentation, statistically I represent so many single individuals, that my vote could be multiplied by a "pretty fight factor". Now the problem is that most of these people just use a search feature but do not understand of configure it. But they will notice when it is gone . These users do not vote, they are not involved in community work, they are not programmers, not system architects, not members of an online community. But they use systems like beagle. I know, as I stated in my first post, some people, which I got to switch their OS, from Windows to openSUSE. These people will miss features, too. Especially if you are so eager so simple remove this feature despite the fact that it was part of the distribution for many years. The more I write here, the angrier I get. I mentioned that Lucifredi and Kulow are of another opinion (disable but no remove the software; make it possible to switch it on or off when needed), an opinion I agree with. Is it possible that YOU ignored that part? This is quite normale for the usual open source community. To me it is a relatively illusive concept, the more I deal with it (and I deal with it for now 9 years) the more I learn about the ignorance it contains. Too many people choose rather to ignore those who have to vote (usually called users) and instead see their opinion as the ultimate measure to decide pro and contra. Did it come to your mind that about 80-90% of those who start to create an account for a portal like openFATE, who pay the time to write some comments and skip through all these proposals in this portal, that 80-90% of these people might perhaps be programmers? Geeks and nerds as they are called nowadays. This is no real statistic representing the opinion of those who use a software, it is a statistic of those how develop a software. Make this clear to you. So to get back on a rather rational level: I recognize that you are of another opinion. That most of the people here are. But, and that was important to me, these votes in here are not a real representation of opinions. I prefer openSUSE after all these years espcially because it was bought by Novell. Because they do research in usability, which is the only real way to ask the customers/the users, how to design the software. That is why I said, that an easy startup QA for the normal user is the best to do. Do not be too ignorant. The users know what they want, even if they miss some technical versatily, they will still take note of features that are missing, of bugs in the browser, of missing parts in the system "that they know worked on a different OS" or whatever else. Perhaps they annot name the source of the problem and do not know if it is a real design issue or a real bug. But they will say that the feature is not how they expected it to be. I recently said to a colleague of mine that the times of Mac OS are nearly over. The only real advantage they have is that they can design an OS without paying too much attention to different hardware. They know exactly which hardware their OS will possible have to run on. If Linux with a nice GNOME, KDE, or-whatever-desktop would run out of the box on ANY posible hardware, with all features running without a problem (Audio, Bluetooth, 3D Graphics are still a problem as we know) it would be undeniable that Linux will be the winner. I see progress made well into that direction. I see that Linux is close to this goal, to solve these issues in nears time (most Graphic Cards now easily work, with only a few exceptions). So please do not disappoint me. I have to lead discussions about Linux/Windows and Linux/MacOSX nearly every week. I do not want to have them led in vain. Look at what Mac and Windows do, they have a search system with an index. Make ours betters, faster and less memory hungry instead of removing it. These who switch from Windows/Mac to Linux (for instance to openSUSE) want to find new and more useful features instead of fewer features. I know this post was too long. I am sorry, but it thought it necessary. #16: Eric Springer (erikina) (2009-02-19 14:33:07) (reply to #15) I agree with everything you said, but you must realize I/we aren't arguing against search. We're arguing against beagle. I personally use google desktop search on a daily basis. And it works well. I assume that it does all its work when I'm not physically using the computer (a policy that is ideal for desktop usage). I'm not advocating its inclusion (primarily license reasons and kde integration reasons) but you should see that I'm not against a search or anything like that. Beagle on the other hand, I've tried to give it a fair shot a few times. To see if it has improved (something I will admit Banshee has done). But its *always* problematic. Something that is echoed daily on IRC and the mailing lists. The firefox extension causes huge amounts errors and slow downs. The actual search program maxs out the CPU. IO brings the computer to a crawl when I need to get work done etc. It's just not pretty. So if Beagle works well, I'd love to use it. But it doesn't and shouldn't be included. Put it this way. I would really like to see kernel initialization of graphics devices. However, until it's finished and works properly -- I think we'd both agree that it shouldn't be on our systems. I know it's not a good test for everything, but have you noticed how many other desktop distros have chosen to include beagle? #17: Sebastian Rösgen (palimpseste) (2009-02-19 18:16:48) (reply to #16) Ok, I see your point. Perhaps beagle is indeed not a good solution and I was too narrow minded to realize it. (Though I haven't experienced the CPU problems anymore for about one year, I suppose you are right). Especially since the development of beagle has come to a crawl (the last release: 0.3.9 was released about four weeks ago but it needed nearly half a year to be released and contains only some mere bug fixes). I think, I am going to open a new feature request in openFate. If you (and the other guys) are not against desktop search, but instead against beagle, it could be interesting to discuss why Tracker (http://projects.gnome.org/tracker/index.html) should not become a replacement for beagle. Especially since KDE has now Strigi as a core component. So one can get rid of beagle and use some "quasi native" tools for desktop search (namely "strigi" and "tracker") on Gnome and, respectively, KDE. Anyway, thanks for your reply and the discussion. #18: Sebastian Rösgen (palimpseste) (2009-02-19 18:23:53) (reply to #17) Hm, as it seems I cannot open such a request. Wonderful! So perhaps somebody has read this discussion and might be so kind to at least evaluate the request and "perhaps" might open a new feature request concerning the replacement of beagle by Tracker (which is a Gnome Desktop search, but since KDE has already its own Desktop search this should not be that problematic... I hope) And before somebody asks: no I will not file a feature request via bug tracking system. Those usually take weeks or even months before they are answered/evaluated/discussed etc... #19: Federico Lucifredi (flucifredi) (2009-02-19 16:52:12) (reply to #18) Hello Sebastian - I do not take the thread as being "against desktop search", which is a great feature, or against Beagle, which I personally run. The decision is only to have Beagle not be running by default out of the box, but to have it installed and ready. The first time a search is performed, we ask. Users who want desktop search select to run it, and those who are more "frugal" in terms of CPU do not. I am running a 3 year old laptop, and Beagle is running just fine for me. I suspect that's the case for a lot of people. But it is still a good idea to ask for a choice. #20: Eric Springer (erikina) (2009-02-22 03:03:55) (reply to #17) 100% agree. I think tracker/strigi make wonderful replacements. :) #22: andrea florio (anubisg1) (2009-02-25 00:40:51) (reply to #20) indeed... beagle is to heavy, traker instead, is simply wonderful! #23: Barbara Hudson (barbie_h) (2009-03-04 02:22:21) (reply to #15) I was going to vote in favour of the request, because I've been bitten by beagle bringing machines to a crawl many times, but one thing I've noticed is that, as people move to dual / quad -core machines, it's no longer a big issue. I'm not saying ignore the memory and resource problems - just that even laptops nowadays can run plasma and beagle and still feel responsive. The current system, where it notifies you when it does the initial indexing, is a lot better than the computer slowing to a crawl on a fresh install and people wondering why openSUSE is soooo slow. #21: Stanislav Visnovsky (visnov) (2009-02-24 09:10:56) Coolo, I believe this should be done via patterns. #24: Stephan Kulow (coolo) (2009-03-04 11:52:23) (reply to #21) having a desktop search easy to enable sounds like a good to have feature, so I wouldn't simply remove the package from install. But it doesn't make sense on a KDE4 desktop (and it's not there in 11.1 afaik) and it doesn't have to be running by default for GNOME either. But this is something for the beagle maintainers to decide. #25: Stephan Kulow (coolo) (2009-03-04 11:53:33) (reply to #24) that is: it should be off by default (seeing all the votes). But if it's worth to make it easier to turn it on than it is, I leave to those that know. But the solution to enable it, should be within the desktop. #27: Jan Engelhardt (jengelh) (2009-03-16 18:03:00) Less than "easy way to disable beagle completey during installation" it should even be "disable beagle by default", thank you. #28: Marcel Müller (open_assistant) (2009-03-16 20:32:45) great idea, especially to my slowly pc #30: Gabriel Stein (gabrielstein) (2009-04-03 21:15:44) Totally Agree. I just post on my blog, and I will pay 5 pints of Guinness to the great developer which will do that amazing thing. + #31: john andersen (jsamyth) (2009-04-16 20:22:51) + I agree Beagle should be an optional item, not installed by default. +   There, I've said it. +   + But an alternative might be to install it and restrict it't indexing BY + DEFAULT to the user's home directory, (and perhaps the user's mail + spool), and hava a configuration window that allows adding additional + directories. + That is a feature that might make it more palletable.  + But realistically, when this many people arrive at a Future Feature + site begging and pleading for a package to dropped from a normal + installation you should assume there are some serious flaws with that + package.  This site should be about new and improved features we + would all like to see, but instead this thread is focused on something + that has been rammed down our throats for way too many releases, and + which has historically been difficult to remove. +   + Side issue: + Unless you are a Linux Developer there is no point in having it index + the entire hard drive.  Your average user has no need of these + areas, and experienced users already know where things are, so a + generalized indexer that searches the entire disk is a solution looking + for a problem. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305285] dictionary and DoS attack protection based using log scanning and dynamic firewall ban
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature changed by: Michael Löffler (michl19) Feature #305285, revision 14 - Title: dictionary & DoS attack protection based using log scanning and - dynamic firewall ban + Title: dictionary and DoS attack protection based using log scanning + and dynamic firewall ban openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) Description: Detailed Description For these attackss, usually the application/service will not allow the attacker to break in, however once a malicious password guess or DoS attack is done, baning the connection for some minutes and then an unban time of several minutes is usually enough to stop a network connection being flooded, as well as reducing the likelihood of a successful dictionary attack. The situation goes this way: - attacker starts a password guess - the system detects Y continuous failed attempts to login in the log file of the service - the system issues an iptables action to block the ip for X minutes. - after X minutes, the ip is allowed again - attacker starts a DoS attack - the system detects Y continuous connections without login - the system issues an iptables action to block the ip for X minutes. - after X minutes, the ip is allowed again Scope To provide an extra option in the firewall which allows to select which services to monitor (usually by looking at patterns in the log file ) and block the ip for a configurable interval once a dictionary attack or DoS is suspected. The option could be as well in the service module (or in both) or even in the specific service configuration module. Usually parameters to configure are the patterns and the actions. Also, YaST should tell the user to install the required packages if this option is enabled. To be defined in the scope is how much configurability is needed. If known services will be protected, or if a generic way to define protection for an arbitrary service is desired. Possible Implementation Fail2Ban provices right now most of the functionality. Provides a service that allows to define jails, a jail is a pattern and an action. A service can have more than one jail. For example the patterns for an ssh DoS attack is different than a dictionary attack on the same service, and the ban times may be different. Fail2Ban provides generic functionality not tied to any specific service and comes with predefined patterns and actions for various popular services as sshd, apache2 http authentication and others. http://en.wikipedia.org/wiki/Fail2ban http://www.fail2ban.org YaST would need to write the configuration about which patterns to use depending on the service to protect, or optionally define patterns for unknown services, same with actions, and start or stop the service depending on this functionality being enabled or not. Test Plan Doing serveral failed attempts on the ssh server should block the user for 3 minutes. Simple testcase. User Experience The functionality should be availabe in a clever location (which can be more than one, for example, firewall, services or the specific module), allowing to turn it on with sane defaults (hopefully provide the defaults fail2ban provides). The user can see the blocked attempts in the logs. Dependencies Using the fail2ban approach would require the fail2ban package, which in turns requires python, available in the openSUSE build service from a community user home project. (home:leonardocf) Contingency Plan None, as the functionality was not available before. Relations: - Preventing Brute Force Attacks With Fail2ban On OpenSUSE 10.3 (url: http://www.howtoforge.com/fail2ban_opensuse10.3) Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:50:52) I don't know about the enteprise angle (I need to think), but for the community distro it seems quite a cool feature. -- openSUSE Feature: https://features.opensuse.org/305285

1 0

[openFATE 304970] YaST UI for pam_mount configuration
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature changed by: Stephan Kulow (coolo) Feature #304970, revision 9 Title: YaST UI for pam_mount configuration openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-09-12 16:48:23 reject reason: Postponing. Priority Requester: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Jiří Suchomel (jsuchome) Description: See bug https://bugzilla.novell.com/show_bug.cgi?id=347144: user requests a way for configuring pam_mount. We already have feature 300967 for some part, maybe other parts of it could be used in samba-client module. Michael, please check which parts might have sense Relations: - inlcude pam_mount in an up-to-date version and provide a YaST - interface for it (novell/bugzilla/id: 0) - https://bugzilla.novell.com/show_bug.cgi?id=0 + interface for it (novell/bugzilla/id: 347144) + https://bugzilla.novell.com/show_bug.cgi?id=347144 Discussion: #1: Michael Calmer (mcalmer) (2008-06-30 11:25:01) Hmm, maybe we should think about a general solution. We use currently pam_mount for encrypted home directiories. Mounting samba shares is requested and now we have a general request to configure pam_mount. The pam_mount configuration is more or less the same like /etc/fstab. It provides all filesystem types which are supported via fstab and some more with special handling from pam_mount directly. The main difference is, that it is possible to have general rules which applies for all users logging-in, groups of users (supporting uid ranges, by guid or guid ranges or group names) and rules which applies only for a single user. For single user configuration a plugin for the users module would be good, but for more general rules a special module would be the best way. Such a module should have an API which can be used by other modules like samba-client to push in special rules needed fo this kind of configuration. -- openSUSE Feature: https://features.opensuse.org/304970

1 0

[openFATE 304970] YaST UI for pam_mount configuration
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature changed by: Stephan Kulow (coolo) Feature #304970, revision 8 Title: YaST UI for pam_mount configuration openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-09-12 16:48:23 reject reason: Postponing. Priority Requester: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Jiří Suchomel (jsuchome) Description: See bug https://bugzilla.novell.com/show_bug.cgi?id=347144: user requests a way for configuring pam_mount. We already have feature 300967 for some part, maybe other parts of it could be used in samba-client module. Michael, please check which parts might have sense + Relations: + - inlcude pam_mount in an up-to-date version and provide a YaST + interface for it (novell/bugzilla/id: 0) + https://bugzilla.novell.com/show_bug.cgi?id=0 Discussion: #1: Michael Calmer (mcalmer) (2008-06-30 11:25:01) Hmm, maybe we should think about a general solution. We use currently pam_mount for encrypted home directiories. Mounting samba shares is requested and now we have a general request to configure pam_mount. The pam_mount configuration is more or less the same like /etc/fstab. It provides all filesystem types which are supported via fstab and some more with special handling from pam_mount directly. The main difference is, that it is possible to have general rules which applies for all users logging-in, groups of users (supporting uid ranges, by guid or guid ranges or group names) and rules which applies only for a single user. For single user configuration a plugin for the users module would be good, but for more general rules a special module would be the best way. Such a module should have an API which can be used by other modules like samba-client to push in special rules needed fo this kind of configuration. -- openSUSE Feature: https://features.opensuse.org/304970

1 0

[openFATE 304937] Wireless dynamic WEP connection with 802.1x authentication in Yast/sysconfig
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature changed by: Stephan Kulow (coolo) Feature #304937, revision 11 Title: Wireless dynamic WEP connection with 802.1x authentication in Yast/sysconfig openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-29 15:43:08 reject reason: This cannot be done in time for openSUSE 11.1. Priority Requester: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Helmut Schaa (hschaa) Description: Yast/sysconfig does already support WPA-EAP wireless connections but is missing support for dynamic WEP connections using 802.1x authentication. wpa_supplicant is able to start such a connection with a network block which uses key_mgmt=IEEE8021X instead of key_mgmt=WPA- EAP. Example: network={ ssid=xxx key_mgmt=IEEE8021X eap=TTLS identity=xxx password=xxx ... } Based on bug #380671 comment #16 and #19. Discussion: #2: Helmut Schaa (hschaa) (2008-07-09 13:34:35) (reply to #1) This request is about dynamic WEP, not static WEP keys (which is already supported). The 802.1x authentication is used to derive dynamic WEP keys repeatedly. It is much more secure then plain static WEP (although not as secure as WPA of course) and still widely used. + #3: Stephan Kulow (coolo) (2009-04-16 14:53:06) + looking for community volunteers -- openSUSE Feature: https://features.opensuse.org/304937

1 0

[openFATE 304911] Import all GPG keys at once before downloading the metadata from new repositories
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature changed by: Stephan Kulow (coolo) Feature #304911, revision 19 Title: Import all GPG keys at once before downloading the metadata from new repositories openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-09 07:54:32 reject reason: Cannot be done in time. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Ladislav Slezak (lslezak) Description: If e.g. 10 different repositories are added yast asks to import the GPG key for each repository so the user cannot leave the computer while the metadata are downloaded. References: https://bugzilla.novell.com/show_bug.cgi?id=399253 Discussion: #2: Federico Lucifredi (flucifredi) (2008-07-08 19:41:45) (reply to #1) cute. It is a nice idea indeed. #3: Dmitry Mittov (michael_knight) (2009-02-23 11:03:50) It is not a good idea to add gpg keys for all repos all over the world. What do you want to do with new repos on BuildService? They can be created after release of new Suse version. All repos signed with SuSE Package Signing Key are guaranteed. When you add other repos you should confirm you trust them. But special option for 'zypper ar'. Something like '--trust-key' will solve you problem. + #4: Stephan Kulow (coolo) (2009-04-16 14:41:15) (reply to #3) + you haven't see the community repos list yet? + #5: Stephan Kulow (coolo) (2009-04-16 14:41:42) + looking for community volunteers -- openSUSE Feature: https://features.opensuse.org/304911

1 0

[openFATE 305313] creating nonexistent directories with Autoyast
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature changed by: Milisav Radmanic (radmanic) Feature #305313, revision 9 Title: creating nonexistent directories with Autoyast openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Uwe Gansert (ug) Description: from bug #429491 It should be possible to create directories just like files with its permissions and ownership. Today it is impossible (using just "files") to put for example /root/.ssh/authorized_keys. To anticipate possible comments, the "file_script" is not IMHO the right way to deal with the problem since it is invoked after writing the file to a filesystem. Yet it may be considered a workaround as of today. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 14:19:55) up for Engineering's comment. Is workaround adequate ? + #2: Milisav Radmanic (radmanic) (2009-04-16 14:06:01) + The workaround is effective but technically not adequate. We should + support creating directories like we do it for files. The request is + off the mailinglist and makes sense. -- openSUSE Feature: https://features.opensuse.org/305313

1 0

[openFATE 303517] Automatically refreshing repositories at recurring intervals
by fate_noreply＠suse.de 16 Apr '09

16 Apr '09

Feature changed by: Stephan Kulow (coolo) Feature #303517, revision 29 Title: Automatically refreshing repositories at recurring intervals openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-09-12 14:12:10 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Ladislav Slezak (lslezak) Description: Autorefresh configured repositories at certain times, this could be on certain days, or time of day, etc. A mockup and more details are in https://bugzilla.novell.com/show_bug.cgi?id=346966 Discussion: #1: Federico Lucifredi (flucifredi) (2008-06-13 15:12:52) there are some caveats I can think of requiring silent fail (for instance, a laptop), or requiring randomization (not hitting NCC with a volley all at the same time), but I think the idea is good. #2: Duncan Mac-Vicar (dmacvicar) (2008-07-07 11:13:37) If you think you can make it work in a reliable way, please present a concept. Right now PackageKit and updater applets do refresh often before checking for updates so the system repos _are_ refreshed. So I don't see much value in this feature (unless a concept is presented). #3: Stanislav Visnovsky (visnov) (2008-07-07 12:34:19) (reply to #2) We have a concept in the automatic online update configuration. #4: Jiri Srain (jsrain) (2008-07-07 12:58:59) (reply to #3) You mean running online update from cron? It should involve metadata refresh, but I do not see any reason for a separate metadata download from cron. #5: Ladislav Slezak (lslezak) (2008-07-09 10:30:09) (reply to #4) The feature should allow to disable "autorefresh" flag for all repositories so the package management can be started quickly without connecting to network. The cronjob would keep the metadata uptodate. Of course, there might be a problem when metadata are changed too often on the server, but in my opinion that's not a usual case in the real world. #6: Jiri Srain (jsrain) (2008-07-10 12:16:08) Let's extend the "automatic online update" module so that it offers whether to do real automatic online update, or just refresh the metadata (via one check box) #8: J. Daniel Schmidt (jdsn) (2008-07-18 18:13:38) (reply to #6) This would hide the feature in an update related module. But the feature does not restrict this only to update repositories. Build- Service Repos might need a refresh as well or think of Factory. The right place for this feature is the Repository Manager. It has no relation to the update process or a configuration concerning updates. #7: Jiří Suchomel (jsuchome) (2008-07-14 14:46:01) Daniel, what's the status of the plan to merge "online update configuration" into registration module? #9: J. Daniel Schmidt (jdsn) (2008-07-18 18:15:46) (reply to #7) Currently I plan to merge it into a new module together with "Online Update Configuration" related settings. Please do not extend it with this unrelated repo refreshing dialog. #10: J. Daniel Schmidt (jdsn) (2008-09-10 19:48:24) Why am I listed as the only developer here? I just said that I will merge the modules "automatic online update setup" and "online update setup". This feature is requesting something completely different. #11: Duncan Mac-Vicar (dmacvicar) (2008-09-10 22:21:17) (reply to #10) Don't worry, this feature will be dropped as because the OnStar work. It is just abandoned. #13: Jiří Suchomel (jsuchome) (2008-09-11 08:20:55) (reply to #11) Really? I don't think so.This feature is aimed for opensuse (it wants to extend the current "online update setup"), while OnStar is for SLE. #12: Jiří Suchomel (jsuchome) (2008-09-11 08:22:02) (reply to #10) Because the requested feature would be part of what is currently "online update setup". And after the merge, I assumed you should mainain the merged parts. #15: J. Daniel Schmidt (jdsn) (2008-09-11 12:37:19) (reply to #12) No the requested feature will not be part of the successor of "online update setup". Maybe you want it to be. But IMHO this has nothing to do with anything that is called "online update *something*". This feature is about a general refresh of repositories - not just the update repo. Software repositories are handled in the "Software repositories" module. And thats the place where this feature is asking for enhancement. Just look at the linked bug (bnc#346966). It even has a mockup (yes, I added one as well, but just look at the original one). And this is now quite the same I already wrote in comment #8. #16: Jiří Suchomel (jsuchome) (2008-09-11 12:44:53) (reply to #15) Ah, sorry. Looks like I have some other feature in mind while commenting this one. This one really is not online-update specific. #19: Robert Davies (robopensuse) (2009-01-16 16:30:40) As when I go into Software Repository management, I am offered check boxes like "autorefresh", it would seem when those boxes are checked, that I expect this to happen without knowing about it. Being made to wait, when I choose to run Online Update, or Software Management, seems to defeat purpose of auto-refresh feature, though it is understandable if no refresh was done for days. Some kind of cron job, ought to just handle this. Why should the user be asked more questions than "autorefresh" tick box? + #20: Stephan Kulow (coolo) (2009-04-16 13:47:23) + looking for community volunteers -- openSUSE Feature: https://features.opensuse.org/303517

1 0