The Open Build Service, a system to collaboratively build and easily distribute packages for a wide variety of operating systems and platforms, has introduced the ability to integrate the intelligent OBS ‘download package’ page into websites. This is useful for projects who want to offer their users easy access to downloads for a wide variety of Linux (and non-linux) systems. Moreover, the Open Build Service 2.3 Release Candidate is out and the final release is near. (more…)
Archive for the ‘Infrastructure’ Category
About 2 weeks ago Thomas “digitaltom” Schmidt of the openSUSE Boosters started working on a refresh of the software.opensuse.org search interface. In that time, he has transformed the quite technical search UI into one which is a lot more modern and far easier to use. But there’s quite a bit of work in designing and building a new way of searching the whole buildservice repository with its 170.000+ packages in an userfriendly and logical way. If you’re up for it, we could use your help!
Thursday 2012-02-02 we will update the SSL certificates for all openSUSE hosts located Nuremberg (see detailed list below). The fingerprint of the new certificate is:
Signed with email@example.com key: pub 2048R/3D25D3D9 1999-03-06 uid SuSE -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 SHA1 Fingerprint=F0:76:9C:42:D3:F1:C0:ED:C6:F6:15:C0:F8:D5:C7:29:60:EB:53:46 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iQEVAwUBTyAnZXey5gA9JdPZAQI7yQf/d4OqlBnV4WT80cqI3DVGGcEacTSES8Ux dK0z9aW/UQWFTHGoQmDk8xcgHED/mHVAlywIPgccbleWNi3NND3+1EAvsxnR5M1m mdVsNYOEsGDrk/3qvPVzyTjkBgINOnetH/0Hd77NhxaDVkU0f1Tl0wbO5NdhKy6m 0dmGwJgUESi3IQjubaibmGZHCZPfEEO0ReW00tRDjFpV4MnU923/BZWT30WuvfMo ClSedk0r6PBt3FGr5yqIFyjM1i3CX/dioW1nJ3qOP1GKMDGLSL20YEY6ZE/F8nL4 bycPLfTjDxKodWXeAmeBlXNTNVYxjphowtjYMQqFe7hXyUkSHBCLLQ== =UhMT -----END PGP SIGNATURE-----
The following hosts will be affected:
We do not expect any service interruptions, but some users run with strict certificate checks.
End of January the US Congress will vote to pass two laws, the “PROTECT IP Act” (PIPA) and the “Stop Online Piracy Act” (SOPA). If these laws pass they would enable copyright holders to get court orders against websites accused of doing or facilitating copyright infringement. So far so good, the openSUSE Project is against copyright violations.
We are a community that provides free and easy access to Free and Open Source Software. We innovate, integrate, polish, document, distribute, maintain and support one of the world’s best Linux distributions. We are working together in an open, transparent and friendly manner as part of the worldwide Free and Open Source community. And in this community there is no room for copyright abuses. That however does not mean that the end justifies the means. We at openSUSE are opposed to the proposals because we depend on our users to not only be able to freely and openly contribute their code but also their opinion and other information. Why that is threatened by these proposals, you can read over at the EFF, or watch this video from Fight for the Future
PROTECT IP / SOPA Breaks The Internet from Fight for the Future on Vimeo.
We hope the decision to blackout openSUSE.org will educate people around the world about this issue that threatens the basics of the internet, will make some US based contributors, friends and users contact their representatives in congress and inspire others to join the strike.
The SAN array of the backend server server lost 3 hard disks over the weekend.
That means the array with the built RPMs was broken. We checked and replaced a lot of files from backups – but since not all binary parts of the projects are in backup we need to rebuild some of them (31 from 24,194) afterwards.
The good news: sources and project configurations were affected by this.
It has been suggested that I write a post explaining some of the big changes that we have been doing with the forums, wikis, and blogs over the last few weeks. Here is a quick list:
- Forums, wikis, and blogs have been moved from iChain to Novell Access Manager
- Wikis have been upgraded to MediaWiki 1.17
- Blogs have been upgraded to the latest version of WordPress
- Blog and wiki servers have been patched to the latest kernel, Apache, and PHP
Now for the details…
Novell Access Manager
Until a couple of weeks ago, the openSUSE blogs, wikis, and forums were running on a product called iChain. iChain is an appliance that acts as an accelerating (caching) proxy that can perform SSO, authorization, and identity injection for applications. While iChain does its job very well, it was discontinued a number of years ago, and it has become increasingly difficult to keep it in service. Some of the major problems are that the hardware it is running on is aging, and it will not run on newer hardware. It is also having trouble with the extensions and field formatting of newer certificates, and it also has a lot of trouble with clients attempting to use newer TLS protocols. Those of you who tried logging in to openSUSE.org with an iOS5 device more than two weeks ago have probably noticed this.
Novell Access Manager is the successor to iChain. While it is slightly more buggy, it has a lot of additional features, and is an actively developed and supported product. Recent builds have also been much more stable and issue-free. It works on a different principle than iChain in that it is based on a federation model. This makes SSO across domains and organizations much easier. For example, openSUSE.org is now single sign-on with www.novell.com and www.suse.com. We can also do SAML 2 federation with other sites, if that ever becomes necessary.
While we are working on moving the rest of the Novell related sites to Access Manager, we are running in what we call “migration mode”. In this setup, iChain continues to handle the authentication for itself and Novell Access Manager. This allows us to retain single sign-on between the two systems as we migrate. As some of you have noticed, a side effect of this is that the openSUSE sites now log in via a Novell-branded login page. When the rest of the sites have been moved off of iChain, we will be able to change back to an openSUSE branded login. This will probably take some time, but we will get there.
Since the openSUSE blogs, wikis, and forums were running on a single iChain server that is out of warranty and irreplaceable, they were among the first sites to be moved to Access Manager. While this provides some benefits, it has also led to a couple of problems that come with being the guinea pig. The first is that we are having a few problems with the IPv6 tunnel that was set up for these sites, and the IDP domain (login.novell.com) does not have an IPv6 address yet. I have reached out to the networking team to get this resolved, hopefully this week. The second is that the default Access Manager timeout is very short compared to what the openSUSE contributors are used to. I changed the timeout to 4 hours last night, so this should no longer be an issue. I know the change has been frustrating for a few of you, but I hope that you can agree that it’s better to work out the kinks now, rather than waiting for the old system to break down.
While MediaWiki 1.17 comes with a lot of improvements, many of you have also noticed that it came with a lot of heartburns. The biggest one was the UTF8 corruption that happened on most of the wikis. This seems to have come from a combination of an outdated collation on the “older” wikis and the way that the update script handled the schema changes. This highlighted a problem that I was not aware of before, which is that there are some major collation differences between the “new” (i.e. English and German) wikis, and the “older” wikis that were not recently rebuilt. After many hours, I found a way to fix the UTF8 corruption, and I also worked with our DBA to get the collation of the other wikis to match the new wikis as best as we could. This should minimize the chance of future upgrade issues.
The WordPress upgrades are usually much easier than the MediaWiki upgrades, and this was no exception. Except for a minor glitch in the theme for logged in users, there are no known issues with the new software.
Similarly to the WordPress upgrades, this was a pretty uneventful change. This update fixes a lot of vulnerabilities, including the “Apache killer” DoS attack discovered over the summer.
We need some maintenance downtime to work on the following issues:
- fix storage problems on Build Service machines
- increase network subnet mask for external available servers (means: we are growing ;-)
- exchange some SSL certificates on servers delivering content via HTTPS
We are trying to get everything done during the standard infrastructure window:
Thursday (2011-11-24), 08:00 – 10:00 CET (7:00 -9:00 UTC)
but some services might need a bit longer (for example the schedulers of the Build Service).
Please contact firstname.lastname@example.org with any queries.
Your openSUSE Admins
The development process of the Open Build Service (OBS) code base as well as it’s accompanying tools is largely test-driven. Major parts of the OBS source code are covered by a comprehensive test-suite. Traditionally, after each new code submission, these tests have been run by a custom shell-script on a local machine that wasn’t publicly available for several reasons. Even though this setup served us well for a long time, but we needed more. We want to provide a more transparent solution that allows the community to participate and maybe take over some responsibilities. Thus, your hard-working OBS-team hereby kindly introduces ci.opensuse.org, our new public interface for continuous integration (CI) testing!
The last few days those of you linked to the planet by http://planetsuse.org/ are experiencing connection problems. This is not because openSUSE Planet is down but as Pascal Bleser announced a few days ago into the openSUSE Project ML because this domain name is not under the Project’s control but by and individual who left the openSUSE Project some years ago.
One of the most important activities during software development is testing. In FOSS community, software often gets tested by the developers themselves, other developers and volunteers. During the openSUSE 12.1 development process it has been important to keep Factory working properly. Testing this is however a rather boring, repetitive task: the tester has to boot up a Factory ISO as often as possible and check if the basic applications start up and work. We don’t like boring tasks so the openSUSE Project has been using the automated testing framework openQA to test this release daily!
This article explains how openQA works and how you can help keep Factory working! We’ll also give some links to more information about testing to help new testers learn the trade but also give experienced testers some new tips and insights!
Testing is generally done on the latest development release, with additional testing sometimes done using updates from Factory to verify bug fixes. Everything in Factory is passed through our automated test framework openQA. You can read more about openQA an the announcement openSUSE News. openQA is a great test suite and is capable of producing videos of the whole process and also screenshots. This greatly reduces the overhead for the testers. An overview of the test results can be found here.
openQA can be used both for bug reporting and bug triaging. To find and report bugs using openQA just visit the openQA test result page, browse through the web interface and look for failed tests. Click on the corresponding tests, to view the results. If your copy of openSUSE is different from the version that has been tested at openqa but you want to/need to do additional testing, fire up your vm and install the version openQA used (or a newer one). You can check for bugs in the tests that have not been autochecked and also look for hardware related (note that in this case you will need to install it on your system instead of a vm) and other possible bugs that openQA might have missed. If you find a bug, report the bug to our testing team or file the bug yourself. Be sure to make good use of the openSUSE Testing documentation at the Testing portal, the Bug report how-to and read the Bug Reporting F.A.Q!
Bernhard, the author of openQA has come out with a nice web interface for bug triagers to make them easier to browse through bugs. The web interface provides with a list of some random bugs. If you are interested ino a scpecific component, then you can use the search bar and look for them. Once you have a random list of bugs that may interest you, you mark a bug as taken. This will reserve the bug. Now fix the bug and update the bugzilla accordingly to get more info or mark it as fixed. While the real triaging is still left for the developers to do, the web interface makes it easierfor them to find bugs..
Adding tests to openQA
An important part of openQA are of course the tests themselves. The more tests are written the more openQA can cover. Tweaking preexisting tests or creating new tests is not very difficult. You can get the sources of openQa from gitorious. You will need it to have the examples and tools needed to build new test cases. Once you have the source, you can find the test modules spread across os-autoinst directory. Every test module has two parts, one which contains the general flow of sendkey events to test an application or feature, the second one being a set of md5 hash sums to determine the validity of test results. os-autoinst/bmqemu.pm can act as a reference for the functions that can be used in our test modules. The commands can be used to write the desired test module. To verify if the test results are valid or not, a set of md5 hash sums of screenshots of the desired results is checked. To calculate these hashsums you can use tools/inststagedetect2.pl. The following article provides an indepth howto on writing a test module in openQA.
If you need help/support in testing, if you have topics to discuss or if you are just interested in this area, join the email@example.com mailing list (see openSUSE:Mailing lists page how to subscribe). Have a look at the Testing portal or directly contact our core testing team