Latest Bugs & Tasks
Links in UserGuide currently point to haiku-files.org
ReadMe and ReadMe.IntroductionToHaiku both contain outdated references to haiku-files.org
The last remaining files still hosted at haiku-files.org needed for a current build seem to be the wifi firmwares, http://www.haiku-files.org/files/wifi-firmwares/
The files affected are:
In an "input" form element, a "keypress" event is not being fired for the "return" key being pressed. The expected outcome is that pressing the "return" key in such a field will cause this event to be fired and that the "keyCode" attribute of the event object will be 0x0d.
This can be seen on the home page of the Haiku Depot Server system at http://depot.haiku.org. On Firefox or Chrome, you can enter a search term in the search field (yellow bar) and press return to initiate a search. With Web+, the pressing of return has no effect.
This is hrev48784.
I've noticed that something flashes on screen after Haiku boots. I've investigated it and it turned out that it was actually mail_daemon's log window. It is reproducible by starting /system/servers/mail_daemon from Terminal.
No stack trace has been provided. It has been probably fixed in the meanwhile.
Tracker used to remember the sorting order for each folder in list mode. It doesn't anymore, and revert to reverse alphabetic, which is rather annoying. It should at the very least use forward alphabetic.
In Tracker in list mode, it used to be possible to scroll up or down by about one page using pageup/pagedown or clicking in the empty areas of the scrollbar. Now this scrolls only by 3 items, which is much less useful and makes it inconvenient to quickly navigate in the file list.
Added in hrev48781. Thanks!
Even for simple changes like this it would be nice to wrap them in a git patch (using git format-patch). This makes sure you get proper credit for your changes, and also allows you to include a commit message describing the changes made.
BeOS and Linux both detect dead network connections, while Haiku doesn't.
This is most annoying when running a BeShare server (Atrus is one, see http://haikuware.com/directory/view-details/internet-network/chat-irc/atrus plus you need the Muscle library too and the muscled daemon). Every time a connection is lost (client turned off their computer without shutting down (often because of a crash), or router was rebooted and didn't close the TCP stream) the result is a dead connection. The BeShare server and Atrus both still see the dead connection as existing, resulting in that user being logged in multiple times. With BeOS/Linux, the dead connection is noticed and disconnected after about a minute.
Maybe something to do with implementing keep-alive packets?
This happens as of hrev48788.
Steps to Reproduce:
- Boot Haiku OS hrev48788
- Launch Webpositive
- Notice that it crashes with a SEG fault
Baron grants sudoable rsync access to the backup user via ssh. This is used for pull-style filesystem syncs initiated from an external server.
In order to restrict the possible damage should an intruder ever get in possession of the private ssh key granting that access on baron, the process should be reviewed and improved.
- The authorized_keys file should be adjusted to limit access only to orange.hirschkaefer.de (and any other backup servers that we might want to use)
- The authorized_keys file should be adjusted to specify the exact command to use for the backup process (possibly a shell script residing on baron containing the exact rsync invocation).
- Instead of sudoing rsync directly, the backup process should sudo a shell script owned by root - this way an intruder can't bend the rsync cmdline to copy out interesting files.
- The rotated backups are currently push-style, i.e. they are being pushed from baron onto the external backup server using another ssh key. From a security perspective, having both push- and pull-style backups to/from the same backup server isn't nice, as a successful attacker on baron could use the push-style backup path to gain access to the backup server, too. Would the rotated backups to be pull-style, too, we could close the access path from baron to the backup server.
vmweb is still running Drupal 6 to provide our main website.
The problem is that Drupal 6 is outdated and doesn't play along with newer PHP versions - PHP fills the logs with lots of warnings about deprecated constructs and it isn't clear if these warning cause actual problems or not.
The sheer amount of modules used by our website make it difficult to maintain, so we should either upgrade to Drupal 7 or even move away from Drupal and rebuild our website by other means.
waddlesplash and puckipedia have shown interest to try and migrate our Drupal 6 installation to the current version of Drupal. Once any of them makes progress with that, we will know whether or not upgrading Drupal is a feasible option at all (it might not be, due to some of the modules we use no longer being available in current Drupal versions).
Upgrading vmweb to openSUSE-13.2 would change php from version 5.4 to 5.6.
As our Drupal6 instance is already exhibiting problems with php-5.4 (it fills the logs with messages about deprecated constructs), it could be that it causes more problems or even complete failure with php-5.6.
So we need to find out if Drupal6 can run on php-5.6 and if/how any related problems can be circumvented.
Resolved in hrev48776.
Our Drupal site running on vmweb is currently using MySQL. In the meantime, openSUSE has switched to MariaDB as default. While this does not have to be bad news, it opens a risk of MySQL not getting the same attention as MariaDB by SUSE.
I suppose it might be advisable to switch to MariaDB, but the work involved is unclear. Maybe it is just a matter of installing the mariadb packages and everything will go smoothly, but before we try, we should read up on the migration process.
Haiku is in need of a code review infrastructure.
In order to let developers/contributors evaluate the different tools available, it would be best to provide test installations.
Here's a (possibly incomplete) list of the potential candidates:
I had started to look into providing those by means of docker images, but that turned out to be somewhat more complicated than I expected. In order to avoid having to install and run docker on baron, I have set up docker on my own server, but so far have only managed to get an instance of phabricator running.
Additional docker images for gerrit and gitlab would be nice. Once we have working images for those, I could host them on my server for evaluation purposes (if needed).
Ticket #11829 (Form an opinion if/which services running on baron directly should better ...) created
Currently, a couple of services run on baron directly:
- buildbot master
- rsync daemon feeding our mirrors
From a security perspective, this isn't very nice, as baron is the hypervisor, which means that any break-in via a service running on it could provide access to all VMs, too. Having those services run in a (maybe additional) VM would limit the risk of an intrusion at least to some extent.
Some of these services (most notable: download.haiku-os.org and the mirror feed) have been put onto baron for a reason: they place considerable demands on network bandwidth and disk space, so moving them to a VM isn't straightforward.
Ticket #11828 (Look into using one-time-passwords as secondary authentication method for ...) created
During last BeGeistert, Jonathan Schleifer suggested to use OTP as secondary authentication method on baron, such that people logging in via ssh would have to produce the appropriate one-time-password, too.
While this kind of two-factor-authentication seems to much of a hassle on things like git.haiku-os.org, I think it makes a lot of sense for baron itself (i.e. the hypervisor machine), maybe even for vmdev and vmweb.
One way of implementing this would be to install and configure the oath toolkit on whatever server we'd like to experiment with first. The respective SUSE-packages are pam_oath and oath-toolkit, provided by the security-repository.
Of course, for this to work, all admins would need to have some compatible client app running on their smartphone, as otherwise they could no longer log in. One of these apps is FreeOTP, but I think Google Authenticator should work, too.
I have no idea whether to use the time-base (TOTP) or event-based (HOTP) algorithm, so the pros/cons of these require some more research.
This link could be useful: http://spod.cx/blog/two-factor-ssh-auth-with-pam_oath-google-authenticator.shtml, this is describing a setup for RHEL/CentOS, but it shouldn't be too difficult to transfer to openSUSE.
Baron and the VMs are currently running openSUSE-13.1, but 13.2 has been published three months ago. I have used 13.2 on several of my own systems without much problems, so I reckon it's safe to upgrade our infrastructure to it.
As usual, one interesting topic could be the upgrading of Postgresql (as newer versions of Postgresql are unable to read older DB formats, so an explicit dump/restore might be necessay). In order to simplify this, openSUSE has started to provide different versions of Postgresql as packages, so hopefully this will be easier this time around.
Another point of interest is that 13.1 introduced a problem with ssh logins using PAM being unbearably slow, which caused me to deactivate PAM for ssh logins. If 13.2 fixes the slowness (and my experience with my own server seems to suggest it does) it would be good to activate PAM again, as otherwise alternative/additional authentication methods like OTP wouldn't be possible to implement.