Latest Bugs & Tasks
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.
Our Trac instance has a tendency to use a lot of memory when there's load on it.
This is partly due to Apache's mpm_prefork module being in use. We should investigate if it can be replaced by mpm_worker or mpm_event.
Additionally, a considerable part of the memory is used by the Postgresql processes serving the DB-connections. As Postgresql apparently doesn't seem to provide a threaded server model, we should investigate if the number of Postgres processes can be reduced without much impact on the performance.
When high load leads to memory pressure, the VM becomes unresponsive rather quickly, so I guess living with a DB using only few processes is better than leaving things like they are now ...
Some of our buildbot slaves fail when they use IPv6 to do a git clone from git.haiku-os.org. The error message is something along the lines of "network unreachable", i.e. indicating a routing problem.
The same buildslaves are able to connect to the buildbot master running on baron fine, most likely using IPv6, too, which leads me to think that only the VMs "behind" baron are affected by the problem.
A likely cause for the routing problems is that we are doing something wrong in our IPv6 setup with respect to router advertisements. AFAICS, baron needs to advertise all IPv6 hosts (i.e. the VMs) in its internal network to the router sitting directly in front of baron.
I remember having had problems when I set up the IPv6 support initially, which had the effect that none of the outside IPv6 traffic targetting any of the VMs was reaching baron (i.e. Hetzner's router must have filtered them out). When I asked Hetzner about it, they told me that they would switch their router to "automatic" mode. I can only assume that this means that the router now passes on all IPv6 traffic targetting our /64 network to baron. Maybe this isn't reliable and the routing stops to work when the VMs haven't produced any IPv6 traffic for some time?
Our services receive quite a lot of unwanted traffic, most notably SPAM-waves hitting our Trac and Drupal instances. Additionally, there are a number of misbehaving web crawlers which produce unnecessary load on our http servers.
Supplementary to fighting the problem for each service individually (by using spamfilters and/or apache redirect rules), it seems like a good idea to try and get rid of at least part of that traffic by applying an IP blacklist filter at baron's firewall. This should reduce the bad traffic reaching baron and all of the VMs running on it.
ipset-blacklist looks like a promising candidate for the job.
We need to investigate how that could be integrated with the SuSEfirwall configuration script, such that the IP blacklist filter persists across reboots.
I am running Haiku on my laptop. I use "Power Save" over "Low Latency" but when ever I reboot my laptop the setting is lost. I would like to to be persistent between reboots.
B_UNDERSCORE_FACE has to be implemented to be used as a font face.
In hrev48768 I changed the code to switch to Mbps only when it reaches 10000 Kbps. It will still not show any decimals, but this leads to a maximal error of 10%, rather than 50% as it was before. the downside is there can be up to 4 digits used to show the speed.
This is hrev48742.
With hrev48660 ActivityMonitor was altered to dynamically change network speed units. As it is now, I find that confusing, largely because the huge rounding errors when you get to 1 Mbps. You get Kbps until 999 Kbps, and then it just displays a rounded 1 Mbps and you don't know if your actual speed is 1.1 or 1.9 Mbps.
As my actual downlink speed often oscilates between a max of 1.6 Mbps and below 1 Mbps, the display changes between informative e.g. 637 Kbps and 1 Mbps.
Maybe the Mbps and upwards (do people already get Gbps?) could show a 1/1000 precision, so there's a smooth transition between e.g. 965 Kbps to 1.287 Mbps.
Or maybe there's a better solution...
This is hrev48760.
Double clicking shortcuts can crash Shortcuts.
- copy attached shortcuts_settings to ~/config/settings
- double click the first empty shortcut
Right-click and select New folder
Nothing happens. No New folder is created.
we seem to be all over the map on our GNU posix extension macros...
/Builds/haiku/headers/posix> grep -R __USE_GNU * regex.h:#ifdef __USE_GNU regex.h:#ifdef __USE_GNU regex.h:# ifdef __USE_GNU regex.h:#ifdef __USE_GNU regex.h:#ifdef __USE_GNU regex.h:#ifdef __USE_GNU regex.h:#ifdef __USE_GNU signal.h:#ifdef __USE_GNU /Builds/haiku/headers/posix> grep -R __USE_GNU *^C /Builds/haiku/headers/posix> grep -R "_GNU_SOURCE" * stdio.h:#ifdef _GNU_SOURCE stdio.h:#endif /*_GNU_SOURCE*/ string.h:#ifdef _GNU_SOURCE string.h:#ifdef _GNU_SOURCE wchar.h:#ifdef _GNU_SOURCE wchar.h:#ifdef _GNU_SOURCE
Our libroot tests also reflect the confusion as they were mixed and some broken.
I think _GNU_SOURCE is the correct way to go... not sure however so I'm opening this for someone smarter than me :-)
- gcc -I./include ./conformance/interfaces/pthread_attr_setdetachstate/2-1.c -g
- LD_PRELOAD=libroot_debug.so ./a.out
KERN: 30030: DEBUGGER: _numBlocks > 0 KERN: debug_server: Thread 30030 entered the debugger: Debugger call: `_numBlocks > 0' KERN: stack trace, current PC 0x1d3a70d4fc9 _kern_debugger + 0x9: KERN: (0x7f1f9b181360) 0x1d3a7178f5e _ZN8BPrivate11processHeap4freeEPv + 0x18e KERN: (0x7f1f9b1813a0) 0x1d3a7179aa0 free + 0x40 KERN: (0x7f1f9b1813c0) 0x1d3a70e2598 pthread_join + 0x88 KERN: (0x7f1f9b181400) 0x13d1368dc42 main + 0x9d KERN: (0x7f1f9b181430) 0x13d1368dac1 _start + 0x51 KERN: (0x7f1f9b181460) 0x7977d707e3 runtime_loader + 0xf3 KERN: debug_server: Killing team 30030 (./a.out) KERN: debug_server: TeamDebugHandler::Init(): Failed to get info for team 30030: Operation on invalid team KERN: debug_server: KillTeam(): Error getting info for team 30030: Operation on invalid team KERN: debug_server: Killing team 30030 () KERN: 30049: DEBUGGER: _numBlocks > 0