December 2011 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 313054] Interface Yast Mail Server connfig POP3/LDAPSMTP and notifications emai client
by fate_noreply＠suse.de 27 Dec '11

27 Dec '11

Feature added by: Scott Couston (zczc2311) Feature #313054, revision 1 Title: Interface Yast Mail Server connfig POP3/LDAPSMTP and notifications emai client openSUSE.org: Unconfirmed Priority Requester: Important Requested by: Scott Couston (zczc2311) Partner organization: openSUSE.org Description: Yast currently has the ability to configure a Mail Server. This configuration is really based on the user having their domain and DNS settings maintained in Opensuse/Apache or direct interface with Domains Managed via a DNS external host. We need to consider that the user many NOT EVEN HAVE A DOMAIN!!!As most Yast applications rely on the preface that every user HAS a domain. This assumption is short sighted and very narrow but has massive commercial applications as we ALL understand! This entire request is based on a user NOT having a Domain to interface..Just a normal user that uses the OPENsuse premise! This additional Enhancement request is in two parts. Firstly to add an additional setup to permit POP3/IMAP/SMTP to interface with locally held email clients of Thunderbird and Kmail etc in Yast Mail Server Creation. The secondly is to add POP3/SMTP/IMAP notifications to many Yast Applications. Many Yast applications don't currently have message notifications sent out with POP3/SMTP/IMAP. Most have only local syslog which really helps NO one on a LAN. This piece of code should be universally available to all yast application that, by nature would benefit for the ability to offer notifications. AppArmour tries to support email notifications, however these are based on sendmail and the fields in AppArmour Notifications will accept anything you enter into the 'email' fields without validation nor the ability to send notification out via POP3/SMTP/IMAP. So firstly on setup of Mail server add functions for POP3/SMTP/IMAP as the third option. Secondly to write code that any Yast applications that can benefit from notifications, enable to call for POP3/SMTP/IMAP fields that are valid validated and function in this way. If no mail server configuration exists call for one to be set-up dependant. Here we also make sendmail notifications as well! If mail server is configured for POP3/SMTP/IMAP then call notifications validated fields and interface AND If mail Server configured as currently opened then then provide fields validated for this purpose and interface. The same should be true for SENDMAIL/PROXY configured in mailserver to call for email validated functionality and fields validation. -- openSUSE Feature: https://features.opensuse.org/313054

1 3

[New: openFATE 313110] "Abort all" or "cancel all" button in Yast2 online update window
by fate_noreply＠suse.de 25 Dec '11

25 Dec '11

Feature added by: Ali H Zadeh (ilAli) Feature #313110, revision 1 Title: "Abort all" or "cancel all" button in Yast2 online update window openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Ali H Zadeh (ilali) Partner organization: openSUSE.org Description: It is a very important needed button. Imagine you clicked on yast2 online update and it started to update repositories and then finding updates, now in the middle of these processes you decide to cancel "online update" and now the headache starts!!! you click on "abort" and it only abort or cancel one process, after a while another repository update process starts and you have to click again on "abort" Button and so on (imagine for example you have 20 repositories)and also you have to hear a load "Beep" sound every time "abort" a process there. OK, another way for doing this function (aborting all process) less suffering is to remove internet cable and disconnect Internet. and i think you are agree with me that this way is not good, specially for a 21th century operating system!!! i think this is a big problem. yast2 online update need a "abort all" button clicking on it lead to closing and canceling all yast2 online update processes. -- openSUSE Feature: https://features.opensuse.org/313110

1 1

[New: openFATE 313026] Do not enable Kwin blur effect by default
by fate_noreply＠suse.de 23 Dec '11

23 Dec '11

Feature added by: Flan Suse (flansuse) Feature #313026, revision 1 Title: Do not enable Kwin blur effect by default openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Flan Suse (flansuse) Partner organization: openSUSE.org Description: By default, if Kwin compositing is enabled / supported on openSUSE KDE (even 12.1), the blur effect is enabled by default. This is a notorious option for KDE's desktop effects that is the culprit for user's effects to run choppy or sluggish, especially if they do not have fairly modern hardware. It happens on any distro. This effect should not be enabled by default. Aesthetically, it does not bring much to the table; however, performance wise, it can create a poor first impression. When browsing forums, it is one the first questions asked when a user complains about poor Kwin performance: "Do you have blur enabled?" Business case (Partner benefit): openSUSE.org: This will give openSUSE KDE a better first impression without losing much (if any) in aesthetics. It will also allow the live KDE CD to work as a better demonstration to the user, especially since it does not use proprietary video drivers. -- openSUSE Feature: https://features.opensuse.org/313026

1 6

[New: openFATE 313090] allow different repo views depending on package management version
by fate_noreply＠suse.de 19 Dec '11

19 Dec '11

Feature added by: Ludwig Nussel (lnussel) Feature #313090, revision 1 Title: allow different repo views depending on package management version openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: Sometimes there are bugs in the software stack that cause unforeseen problems when e.g. the update repo grows bigger and bigger over time. In the worst case the software stack might not be able to install updates at all anymore. We should have a defined way to avoid such situations. My proposal would be to make zypp look for a differently named entry point to the repo first before falling back to repomod.xml. E.g. 'repomd-XX.xml' where XX is some internal revision counter. That way it would be possible to present only a minimal working repo to the unpatched software stack that allows it to install an update for itself. By using an optional extra file incompatibilities with other software stacks are avoided ie other repo parsers would always use the full repo. -- openSUSE Feature: https://features.opensuse.org/313090

1 0

[New: openFATE 309587] Easier SUSE bugreporting
by fate_noreply＠suse.de 16 Dec '11

16 Dec '11

Feature added by: Michal Vyskocil (mvyskocil) Feature #309587, revision 1 Title: Easier SUSE bugreporting Requested by: Michal Vyskocil (mvyskocil) Partner organization: openSUSE.org Description: Last hackweek I hacked up the susereport [1] a port of Debian's reportbug script. Susereport deals with a BuildService - can find the assignee from package/project metadata. It basically works, but needs to be tested more than is. So my hackweek project will be test it and release it! And also find some nice to have features (like automatic information gathering in some cases, or so). [1] http://gitorious.org/+opensuse-developers/opensuse/susereport [2] http://www.debian.org/Bugs/Reporting Business case (Partner benefit): openSUSE.org: Novell bugzilla is not nice - you have a zilions projects/products and you just have to fill a bug against openSUSE. Existence of BuildService complicates it, you need to know from which project you have a buggy package and who maintain that crap ... susereport solve all of those questions to one - Why there are so much questions, isn't there any easier way? -- openSUSE Feature: https://features.opensuse.org/309587

1 4

[New: openFATE 308353] get rid of mandb cron job
by fate_noreply＠suse.de 15 Dec '11

15 Dec '11

Feature added by: Ludwig Nussel (lnussel) Feature #308353, revision 1 Title: get rid of mandb cron job openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Description: /etc/cron.daily/suse-do_mandb runs every day to create the man page indexes and the whois databae even if no package was installed. This exercises the hard disk quite a bit. A smarter solution would be to update the index and whois db each time a manpage gets added or removed, just like it's done with info pages. -- openSUSE Feature: https://features.opensuse.org/308353

1 4

[New: openFATE 310263] By default use a functioning version of Java
by fate_noreply＠suse.de 14 Dec '11

14 Dec '11

Feature added by: Andrew Joakimsen (joak0) Feature #310263, revision 1 Title: By default use a functioning version of Java openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Andrew Joakimsen (joak0) Description: The "OpenJDK" version of Java is installed by default in openSUSE. This version of Java does not enjoy widespread compatibility. I have yet to find a site that properly works with this Java implemenaton and have promptly replaced it with a working Jave implemenation -- Sun. The installation of the working Java plugin should be via the same mechanism that is employed to install Flash plugin upon the first update to the system (pullin-flash-player package). Until the point in time it can be demonstrated that the OpenJDK implementation can work with >= 95% of Java applets encountered in "the real world" it should not be included by default in OpenSUSE. I think it is a way better out-of-box experiance for users to have to install Java (just like in Windows) vs. appear to have Java but "Java is broken in openSUSE" I doubt many non-technical users can understand the difference. -- openSUSE Feature: https://features.opensuse.org/310263

1 4

[openFATE 305546] Support for NTLM authentication (proxy) in YaST and libzypp
by fate_noreply＠suse.de 14 Dec '11

14 Dec '11

Feature changed by: Yury Krasovski (krasoffski) Feature #305546, revision 29 Title: Support for NTLM authentication (proxy) in YaST and libzypp openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 18:02:44 reject reason: out of context for openSUSE. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.3: Evaluation by product manager Priority Requester: Desirable Package Wishlist: Unconfirmed Priority Requester: Important Info Provider: Federico Lucifredi (flucifredi) Requested by: Katarina Machalkova (kmachalkova) Product Manager: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: YaST and libzypp should work in an environment with proxy server requiring NTLM authentication. The feature consists of two parts: 1) YaST proxy module has to provide UI to let user choose NTLM and write configuration file (/root/.curlrc) accordingly 2) libzypp media backend needs to be adapted to read and understand such configuration( that is, accept also --proxy-ntlm option instead of bare --proxy only) References: https://bugzilla.novell.com/show_bug.cgi?id=440296 https://bugzilla.novell.com/show_bug.cgi?id=412137 Relations: - Cntlm Authentication Proxy (url: http://cntlm.sourceforge.net/) Business case (Partner benefit): openSUSE.org: Significant for adoption in mixed datacenters where the proxy infrastruture is on MSFT assets. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:57:23) Sadly, there is a realistic business case for this in mixed datacenters. Some odd people like to use NTLM proxies, I will never understand why. this will be a headache to do :-/ #2: Mark Muhlestein (mmuhlestein) (2010-01-13 18:10:39) Many of the engineers at Dell Computer in Austin want to use openSUSE 11.2 on their desktop machines. Dell uses a NTLM proxy on their corporate network so a lack of this functionality is keeping them from doing so. This group of engineers are very loyal SUSE/Novell folks who are trying very hard to help a SUSE desktop make inroads into Dell's corporate environment. Current number of engineers who cannot use the product is 50 - 60 On a side note, they see this a glaring problem. I don't know how many corporations use NTLM proxies but the gents at Dell seem to think it is quite a lot. #3: Katarina Machalkova (kmachalkova) (2010-01-14 15:03:36) I was wondering whether aria2c can handle NTLM auth. curl certainly does, but it's not our default downloader anymore. I googled a bit and found this table (http://curl.haxx.se/docs/comparison-table.html) and it doesn't look too positive :( #4: Duncan Mac-Vicar (dmacvicar) (2010-01-14 16:51:17) Because we are now using aria2 (however ZYpp stll can fall back to curl) I asked aria2 author if he planned something in the direction. He does not, however he will look into the protocol. The problem, appart of the time, is that he does not have a server to test. He pointed me to http://ntlmaps.sourceforge.net/ which allows to authenticate against a NTLM server acting as a normal proxy server. I have never tested this, but I wonder if companies really need support for this protocol in the tooling. #5: Michael Calmer (mcalmer) (2010-01-14 16:57:35) (reply to #4) I would say yes. I see sometimes logs from the registration where is a proxy is in use with NTLM authentication. I think this is some kind of Windows Server which is doing the authentication and automatically support NTLM. If possible, we should have a way to support this. #7: Michael Andres (mlandres) (2010-08-10 15:32:24) (reply to #4) Might be worth mentioning that post 11.3 we're about to drop aria2 again. We now have a builtin solution suporting metalink and zync, base on libcurl. #6: Carlo Baffè (cbaffe) (2010-08-05 14:04:03) also Telecom Italia (http://www.telecomitalia.it) asked us about this feature support since their SLES / SMT should pass through MSFT ISA proxies with authentication in order to reach our nu.novell.com. but SLES 11 SP1 does not support it. #9: Andi Chandler (andibing) (2011-12-01 19:58:54) NTLM authentication should be an option in YAST to work seamlessly across all services. #10: Duncan Mac-Vicar (dmacvicar) (2011-12-05 09:27:32) (reply to #9) Has anyone really tried this? I can see in ZYpp code > grep CURLOPT_PROXYAUTH * MediaCurl.cc: SET_OPTION(CURLOPT_PROXYAUTH, CURLAUTH_BASIC|CURLAUTH_DIGEST|CURLAUTH_NTLM ); Which means NTLM is enabled. #12: Michael Calmer (mcalmer) (2011-12-05 10:04:30) (reply to #10) I had this enabled for SMT and a customer was able to authenticate to a proxy.So I went to zypp team and they have enabled this too. I think it is part of 12.1 and Factory, but not on older versions. #11: Duncan Mac-Vicar (dmacvicar) (2011-12-05 09:59:45) (reply to #10) Oh, I just realized this commit is only a few days old. This should enable NTLM support, but it needs to be tested. It will be in next openSUSE, SLE service pack or major version. If we need a backport we can do it, but it needs to be tested. commit 3524f4d265a9c697fb201977f60cc7eba3570250 Author: Michael Andres <ma(a)suse.de> Date: Thu Oct 20 15:57:02 2011 +0200 Set CURLOPT_PROXYAUTH diff --git a/zypp/media/MediaCurl.cc b/zypp/media/MediaCurl.cc index cb27760..901ac45 100644 --- a/zypp/media/MediaCurl.cc +++ b/zypp/media/MediaCurl.cc @@ -620,6 +620,7 @@ void MediaCurl::setupEasy() if ( ! _settings.proxy().empty() ) { SET_OPTION(CURLOPT_PROXY, _settings.proxy().c_str()); + SET_OPTION(CURLOPT_PROXYAUTH, CURLAUTH_BASIC|CURLAUTH_DIGEST| CURLAUTH_NTLM ); /*--------------------------------------------------------------- * CURLOPT_PROXYUSERPWD: [user name]:[password] + #13: Yury Krasovski (krasoffski) (2011-12-13 16:06:41) + NTLM is very important feature for me, because I have to use proxy with + NTLMv2 authentication. I hope, I'll get it in next release, and also I + recommend to use a cntlm package. -- openSUSE Feature: https://features.opensuse.org/305546

1 0

[New: openFATE 312940] zepe app server
by fate_noreply＠suse.de 13 Dec '11

13 Dec '11

Feature added by: mohammad arabnezhad (mohsuse) Feature #312940, revision 1 Title: zepe app server Buildservice: Unconfirmed Priority Requester: Important Requested by: mohammad arabnezhad (mohsuse) Partner organization: openSUSE.org Description: this is a test -- openSUSE Feature: https://features.opensuse.org/312940

1 1

[New: openFATE 311133] Heroku like solution for SUSE Studio
by fate_noreply＠suse.de 12 Dec '11

12 Dec '11

Feature added by: Flavio Castelli (flavio_castelli) Feature #311133, revision 1 Title: Heroku like solution for SUSE Studio Hackweek VI: Unconfirmed Priority Requester: Neutral Requested by: Flavio Castelli (flavio_castelli) Partner organization: openSUSE.org Description: Creating an appliance to run a specific rails appliacation can be quite annoying. There are extra repositories to add, package dependencies to satisfy, a database to setup, apache and passenger to setup, overlay files to add and so on. Cloning an appliance like this (http://susegallery.com/a/CZ0T0D/rails-in-a-box) can save some time, but some efforts are still required. IMHO the easiest solution to deploy a rails app in the cloud is Heroku (http://heroku.com/) . My hackweek project (temporarly called 'Dister') aims to provide a command line tool similar to Heroku's one. This is a list of the possible commands I want to implement. dister create [base_system] [template] base_system and template are optional parameters. If base_system is not set dister will use latest version of openSUSE supported by Studio. If template is not set dister will use the JeOS template. dister push pushes the current rails code to studio dister rake db:migrate performs all the db migrations locally and uploads a dump of the db to Studio dister add format <format> adds the specified format dister rm format <format> removes the specified format dister packages add <package> adds package to the appliance dister packages rm <package> removes package from the appliance dister build builds the appliance dister download downloads the appliance locally dister testdrive boots the appliance inside of testdrive and returns SUSE Studio is going to support direct deployment of ec2 appliances to Amazon. Supporting this feature inside of my hackweek project would make terribly easy to push rails appliances into the cloud. Test Case: * User checkouts his rails app from git/svn/whaterver * User creates a new appliance using: dister create * dister figures out which database is used by the rails appliance and adds all the required packages. * dister figures out which gems are required by the rails app and installes them from rpm or from gem files. * User updates a dump of his db using the command dister rake db:migrate * dister configures apache passenger automatically * User requires an extra package using the command dister package add ImageMagick * User enables VMware format dister add format vmx * User builds the appliance dister build * User tests the appliance inside of testdrive dister testdrive * User downloads the appliance dister download Business case (Partner benefit): openSUSE.org: Attract more rails developers, create more appliances. -- openSUSE Feature: https://features.opensuse.org/311133

1 5