June 2012 - openSUSE Features - openSUSE Mailing Lists

[openFATE 307846] Kolab groupware server support by openSUSE
by fate_noreply＠suse.de 20 Nov '13

20 Nov '13

Feature added by: Richard Bos (rbos) Feature #307846, revision 1 Title: Kolab groupware server support by openSUSE openSUSE-11.3: Unconfirmed Priority Requester: Neutral Requested by: Richard Bos (rbos) Description: Kolab (http://kolab.org) is a free and open software groupware solution. It allows seamless support of mixed clients environments (Outlook/KDE/Web). The following functionality is provided by kolab; groupware (free/busy information), email, spam and virus filtering, a webinterface for the system administrator and end user. The web interface can be used to add, modify and remove users, domains, distributions list, shared folders, among other things. Kolab is build from only open source software, and the data it stores is freely available by the end user. This means that if the end user is not satisfied with the provided service delivered by the service provider, the end user can retrieve his or her data and move it to somewhere else. The Kolab groupware server is assembled with postfix, cyrus, amavis, openldap, apache among other open source projects. Due to its design the kolab server supports multiple domains and thousands of end users. Clients that can be used with Kolab groupware server are for example KDE's kontact, horde, MS Outlook in combination with a connector. Kolab for openSUSE has been available for a long time already, but it was always necessary to patch multiple projects to provide all (groupware) functionality. Since September 2009, it is only necessary to extend cyrus with some patches to get the required functionality. Hence in order to have Kolab working on openSUSE cyrus must be patched. The patched cyrus version can be retrieved from the build service. Kolab is it worth to be supported by openSUSE as it is composed of only open source software, it supports thousands of end users, and very unique end users have full control over all their data including their groupware information! -- openSUSE Feature: https://features.opensuse.org/307846

1 21

[New: openFATE 310147] Single login setup for Evolution and Goggle
by fate_noreply＠suse.de 28 Oct '13

28 Oct '13

Feature added by: Drew Kwashnak (dragonbite) Feature #310147, revision 1 Title: Single login setup for Evolution and Goggle Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: Drew Kwashnak (dragonbite) Partner organization: openSUSE.org Description: Evolution handles connecting to Google mail, calendar and contacts but each piece has to be set up seperately. Have Evolution, when connecting to a Gmail account, offer the option to also connect the users' calendars (providing a list of calendars they can choose from) as well as sync their contacts. If Google tasks are likewise available, offer to include those as well. This would supply the closest equivalent to the ease of setting up Outlook and Exchange. Use Case: Bob is a developer doing some work on his own and wants something similar to work's Exchange server/Outlook setup. He has a Google account and uses multiple calendars for different activities (personal, school, work, events, club, etc.). He wants to quickly set up his Google account as his "Exchange" (mail, calendar, contacts). Months later, he gets a Netbook to travel to client's sites with for demonstration purposes. He wants to have the same Evolution setup on the netbook but doesn't want to have to set each piece again by hand. The following year he decides to get a more powerful and updated laptop, and wants to set up his Evolution again without having to set up each piece all over again. The next version of openSUSE is released and he decides to do a clean install rather than an update. Business case (Partner benefit): openSUSE.org: 1. Provides the easiest "Exchange-like" situation for Linux. 2. Provides an easy way to connect Evolution to Google for multiple machines, new machines and after upgrades. 3. Provides a framework that could be used for other Services if there is a need. 4. Help less-technical users get up-and-running quickly and easily. -- openSUSE Feature: https://features.opensuse.org/310147

1 1

[New: openFATE 310695] boot with gag or similar by default
by fate_noreply＠suse.de 28 Oct '13

28 Oct '13

Feature added by: pier andre (pier_andreit) Feature #310695, revision 1 Title: boot with gag or similar by default openFATE: Unconfirmed Priority Requester: Desirable Requested by: pier andre (pier_andreit) Description: dear developers, I'm a user, simple user, not advanced or power, only simple, one of the problem of a user like me is the bootloader, as simple wannabe better users usually do I have a double or triple boot pc, the first is windows becouse my fear to have a pc which cannot use some software, the second is suse linux with stable repository becouse I would like to learn and work with it and the third is suse linux factory updated becouse my curiosity to try new software is big but the fear to have a system crapped exist. Sometimes happen that I have to reinstall some operative system or I would like to try another distribution, this turn me in a dark tunnel about bootloader, where to install it, which install, does windows and suse restart again? in the past happened the mess :-). Why don't adopt by default a software like this or similar or the idea? GAG, the Graphical Boot Manager (http://gag.sourceforge.net/) it could be improved and installed in a its own separate little partition, it will eliminate the doubt and the choice on where and which bootloader to install, installing the grub or lilo or other in the partition where the new installation is performed and gag in his own dedicated partition. thanks of any attention Pier -- openSUSE Feature: https://features.opensuse.org/310695

1 4

[openFATE 306960] support update of systems with encrypted physical volumes
by fate_noreply＠suse.de 28 Oct '13

28 Oct '13

Feature added by: Arvin Schnell (aschnell) Feature #306960, revision 1 Title: support update of systems with encrypted physical volumes openSUSE-11.3: New Priority Requester: Mandatory Requested by: Arvin Schnell (aschnell) Description: Since openSUSE 11.2 can install systems with encrypted physical volumes (see fate #305633) openSUSE 11.3 must be able to update such systems. -- openSUSE Feature: https://features.opensuse.org/306960

1 14

[openFATE 307745] Let the admin ("root") download and install untrusted third-party RPMs from known URLs guided via YaST
by fate_noreply＠suse.de 24 Oct '13

24 Oct '13

Feature added by: Johannes Meixner (jsmeix) Feature #307745, revision 1 Title: Let the admin ("root") download and install untrusted third-party RPMs from known URLs guided via YaST openSUSE-11.3: New Priority Requester: Neutral Requested by: Johannes Meixner (jsmeix) Description: I would like to have it evaluated whether or not it is allowed to implement a dialog in YaST which lets the system admin (i.e. "root") download and install untrusted third-party RPMs from known URLs. In any case "root" can download and install any software manually. This reques is about to provide a guided and restricted way for some particular cases. My current use-case are the printer driver packages which are available via OpenPrinting at the Linux Foundation: http://www.openprinting.org/driver_list.cgi where LSB compliant driver RPM packages are available. >From my point of view those packages are on the one hand untrusted third-party RPMs but on the other hand their download location is "well known" which makes those packages "well known third-party packages". I assume that from a strict security point of view any kind of third party software is "strictly forbidden" but I like to propose a more useful way here: The system adminj (i.e. "root") can in any case download and install whatever software he likes. This man invalidate e.g. whatever support contract but it is up to the admin to know what he does. Currently we have no idea at all which third-party printer drivers an admin may download an install on his own. When he has a printer for which there is no driver provided by us, the admin may download whatever driver software from any totally unknown location and install it with any unknown consequences. (E.g. some time ago there was a printer driver from a printer manufacturer where its installation script set setuid root bits on various user application programs to mak it "just work".) Currently we even do not tell the admin about the well known printer driver locations at OpenPrinting. >From my point of view it would be a big improvement when I could implement a dialog in the YaST printer module which shows a very explicite text that this is about untrusted unsupported third-party software. This text would require explicite confirmation by the admin. Then it downloads RPMs only from hardcoded URLs from OpenPrinting and inspects the downloaded RPM whether it overwrites already installed files on the system and if not, it installs it without running any RPM scripts because normal printer drivers do not need to run RPM scripts during installation. If the above conditions are not fulfilled it shows a very explicite warning text and does not install anything. In contrast to now where we leave the admin totally on its own how to get a driver for a printer for which we do not provide a driver, the above described guided and restricted way to download and install drivers via YaST would help both the admin and us because in many cases we could make sure this way that we know at least which third-party driver the admin has installed. Please do not confuse this request with the different request how a third-party (e.g. OpenPrinting or a printer manufacturer) could provide software packages in a way which is in full compliance to our package installation and management tools (i.e. via a repository which provides also updates and so on). This request is meant for third-party RPMs "as is" where the vendor/provider simply does not want (because of whatever reason which is beyond our control) to provide his RPMs in compliance to our package installation and management tools. -- openSUSE Feature: https://features.opensuse.org/307745

1 9

[New: openFATE 313496] get rid of world writable directories
by fate_noreply＠suse.de 23 Oct '13

23 Oct '13

Feature added by: Ludwig Nussel (lnussel) Feature #313496, revision 1 Title: get rid of world writable directories openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: We should get rid of all /tmp like world writable directores besides /tmp and /var/tmp themselves. This reduces the number of places where users could store extra files that don't belong there. Also reduces security risks caused by programs operating on such insecure directories. Candidates: /var/lib/xemacs/lock/ /var/run/uscreens/ /var/spool/uucppublic/ /var/tmp/vi.recover/ /var/spool/mail/ /var/cache/fonts/ -- openSUSE Feature: https://features.opensuse.org/313496

1 1

[New: openFATE 311338] YaST debconf Module
by fate_noreply＠suse.de 13 Oct '13

13 Oct '13

Feature added by: Lars Vogdt (lrupp) Feature #311338, revision 1 Title: YaST debconf Module openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Lars Vogdt (lrupp) Partner organization: openSUSE.org Description: Currently, people installing RPM packages have no opportunity to configure the installed applications afterwards with openSUSE Tools - if there's no specialized YaST module. This is a disadvantage comparing to Debians debconf system, allowing packagers (and therefor endusers) asking the user certain configuration questions after installation. Goals * A first part will be a GUI reading currently availble debconf templates and displaying them as expected. Please have a look at the debconf specifications for this. * If this proof of concept works, there's a need for support of such templates in RPM. We need a general policy describing how RPM packagers can include such template files in their packages. This would give openSUSE the great benefit of helping Debian people to migrate to openSUSE - and (more important) allows packagers to allow users customizing their installation without writing special YaST modules. Scope Remember that debconf doesn't cover all configuration aspects of any application. It should be enough to ask some general informations so that an application is ready for usage afterwards. A fine granulary configuration should been done by hand - or the according YaST module. Related technologies Tools that interact : * libzypp * mod_ui (YaST) * rpm Typical use case In the end, a user should be able to install a package like MySQL - and configure main parts of his new application using the YaST debconf module. Also think about packages for applications using a database, such as web based applications like horde, moodle and so on - currently, the user has to create the needed database manually. The YaST debconf module could ask for the location of the database server, the database name, the username, ... - and use this informations to set everything up so a user can login to his application right afterwards. Business case (Partner benefit): openSUSE.org: debconf is a software utility for performing system-wide configuration tasks on Unix-like operating systems. It is developed for the Debian GNU/Linux distribution, and is closely integrated with Debian's package management system, dpkg. When packages are being installed, debconf asks the user questions which determine the contents of the system-wide configuration files associated with that package. After package installation, it is possible to go back and change the configuration of a package by using the dpkg-reconfigure program, or another program such as Synaptic. The design of debconf allows for front-ends for answering configuration questions to be added in a modular way, and there exist several, such as one for dialog, other for readline, one for editor, one for KDE, one for GNOME [1], a Python front-end API, etc. There are two differnent goals for openSUSE: * Add some kind of "debconf" support to RPM * Create a YaST Module as front-end -- openSUSE Feature: https://features.opensuse.org/311338

1 3

[New: openFATE 310455] list packages that trigger build
by fate_noreply＠suse.de 08 Oct '13

08 Oct '13

Feature added by: William Brenneman (eocrates) Feature #310455, revision 1 Title: list packages that trigger build Buildservice: Unconfirmed Priority Requester: Desirable Requested by: William Brenneman (eocrates) Description: I have packages that use the openSUSE_Factory repo, and periodically a required package will be updated in the repository that triggers my packages to be rebuilt. Suggection: list what package (and version # => version #) in Commit History of my package that triggered my package to rebuild. -- openSUSE Feature: https://features.opensuse.org/310455

1 10

[New: openFATE 312816] Continuous YaST Testing in Jenkins
by fate_noreply＠suse.de 04 Oct '13

04 Oct '13

Feature added by: Lukas Ocilka (locilka) Feature #312816, revision 1 Title: Continuous YaST Testing in Jenkins Hackweek VII: Unconfirmed Priority Requester: Important Requested by: Lukas Ocilka (locilka) Partner organization: openSUSE.org Description: Continuous testing in Jenkins is widely used by several projects, such as: libzypp, slms, studio... to find issues ASAP, but YaST still lacks this possibility. Jenkins URL: http://river.suse.de/ More info on the subject can be found at this thread: http://lists.opensuse.org/yast-devel/2011-06/msg00096.html -- openSUSE Feature: https://features.opensuse.org/312816

1 1

[New: openFATE 309679] YaSTroid
by fate_noreply＠suse.de 04 Oct '13

04 Oct '13

Feature added by: Jared Allen (jpallen) Feature #309679, revision 1 Title: YaSTroid Requested by: Jared Allen (jpallen) Description: YaSTroid - An Android phone application to manage your SLES server using the WebYaST back-end. -- openSUSE Feature: https://features.opensuse.org/309679

1 14