Nagios is probably one of the most used network monitoring systems around. Especially in environments that have been around for a while and contain a lot of on-premises nodes.
I've recently started to upgrade an existing installation which included a lot of automation and updating from Nagios Core 3.x to Nagios Core 4.x. This resulted in an updated Web Interface with more PHP code and a more modern design.
One main gripe I have about the Nagios interface however is the use of Frames. The problem has not changed since the 3.x days:
Despite these complaints, frames can actually be very useful in many cases. When developing your own software, there are multiple options available to work around these frameset limitations. When using third-party software such as Nagios however, there's fewer options available.
For Nagios Core 3.x I had replaced the Nagios provided index.html page with my own index.php page that takes an optional parameter for the address of the main frame which allowed to construct URLs that open the regular Nagios interface with the navigation bar on the left frame and a e.g. specific service opened on the main frame to the right.
When porting this functionality I stumbled the fact that Nagios Core 4.x is already using PHP for some files and the default index.php already seems to have a parameter called "corewindow" that seems to offer this functionality. Unfortunately, there is barely any documentation around for this parameter. The first thing I found is a ChangeLog entry (https://www.nagios.org/projects/nagios-core/4x/) indicating this functionality is disabled by default due to a potential security vulnerability:
4.3.0 02/21/2017
Security
- Fix for CVE-2016-6209 The corewindow parameter (as in http://localhost/nagios?corewindow=www.somewhere.com) has been disabled by default. See the UPGRADING document for how to enable it.
Well, Duh. If you take random URLs and use them to build a frameset defintion, this can indeed be "misused" to open a random URL inside your Frameset.
Personally, I wouldn't consider this a case of "works as designed" and not as a security issue but of course hapless users might be confused. Probably depends a lot on the users.
But this is exactly the functionality we need except it's disabled. The UPGRADING document states that one can re-enable the corewindow functionality using the --enable-corewindow Parameter when building Nagios.
But re-enabling said functionality is even easier. Just change line 4 in the index.php file from
if ("no"== "yes" && isset($_GET['corewindow'])) {to
if ("yes"== "yes" && isset($_GET['corewindow'])) {Done, that's the same thing the --enable-corewindow parameter does.
If you now open /nagios/index.php?corewindow=nagios/tac.cgi the index file will open the Tactical Overview screen. Nice!
Functionality restored using the default installation. Perfect!
But can we improve things?
While looking for documentation for the corewindow parameter, I stumbled over Custom CGI Headers and Footers on the Nagios documentation. It seems the CGIs can load files and embed them in the HTML page...
This is brilliant. We can use some low key JavaScript logic to automatically update the browser location bar to add the corewindow parameter with the right link to the CGI.
This way, the location bar will always show a link to the specific view we're looking at right now and can be easily copy and pasted. No more right-click->frames->copy-frame-link dance.
This means we can create a file /usr/share/nagios/html/ssi/common-header.ssi drop some Javascript in there that handles the updates of the location bar and we're done. Awesome. The code needed is super simple:
<script> /* * Update the browser location bar to ensure ?corewindow= always contains the URI * to the current page. * * This allows a reload to reload the same page rather than going back to the main * frameset. */ // Get the current URL of the parent window (assuming the frame is nested within it) var parentUrl = window.parent.location.href; // Get the path of the file from the current URL of the frame var filePath = window.location.pathname; // Remove the first slash from the path name filePath = filePath.substring(1); // Get any query string parameters passed to the file var queryString = window.location.search; // Remove any existing corewindow parameter from the query string queryString = queryString.replace(/(?:&|\?)corewindow=[^&]*&?/g, ''); // Construct the new query string with corewindow as the first parameter var newQueryString = 'corewindow=' + filePath; // Append any existing query string parameters if (queryString) { // Emcode only the '?' and the '&' component of the path. newQueryString += encodeURIComponent('?') + queryString.substring(1).split('&').join('%26'); } // Construct the updated URL with the new query string var updatedUrl = parentUrl.split('?')[0] + '?' + newQueryString; // Replace the URL of the parent window with the updated URL window.parent.history.replaceState(null, null, updatedUrl); </script>
And done, now clicking inside the Nagios interface will update the location bar to URLs such as https://nagios.example.com/nagios/?corewindow=nagios/cgi-bin/extinfo.cgi%3Ftype=2%26host=filer-cluster%26service=fs_%2Fdev%2Fvg%2Barc_vol_000%2Flv%2Bn%2Blvarc_vol_00000 which is a link that opens the fs_/dev/vg+arc_vol_000/lv+n+lvarc_vol_00000 service on the filer-cluster host. Easy to share. Perfect.
Unfortunately, this solution is as close to perfect as we can build it using the shipped functionality, but it's not 100% perfect.
Further reading:
Other people also have been using the SSI functionality to embed funky Javascript functionality. https://theezitguy.wordpress.com/2015/08/16/nagios-improve-user-experience-with-ssi-and-javascript/ is a good example.
At bawue.net we are using several Avocent PM 3000 power distribution units to connect our servers.
A nice feature of these PDUs is that they work great with our existing Cyclades console servers.
In addition to the serial console and the SSH interface, these devices also offer a web interface. This interface never worked with Chrome or Chromium where it only shows a blank page. It does however work with Firefox, or so I thought at least.
I recently needed to verify something and found out that with the latest Firefox the webinterface on these devices is now not broken. Empty page, same as with Chrome.
As there is no firmware upgrade, I tried figuring out what is going on.
It turns out, the web interface was written using the JavaScript document.load() function to fetch content from the device. Unfortunately, this function was never standardized, never supported on Chrome or Safari and has by now been removed from Firefox as well.
Bummer!
But thanks to Greasemonkey or Tampermonkey it is possible to make the web interface work again. We just need to provide a document.load() function that uses AJAX/XHR Requests to load data from the device and all is good.
Such a userscript can be found on my public github gist.
Avocent (formerly Cyclades) is a supplier for various datacenter management tools. They are best known for their rackmounted power distribution units and their serial console servers. Both devices run Linux and have been around for years.
Both the now EOL'd devices from Cyclades as well as the newer devices from Avocent can powercycle devices either through a serially attached smart PDU or through IPMI. Every device under the Advanced Console Server (ACS) label can control IPMI devices with a recent firmware.
While the functionality of the attached PDUs is quite well documented, there's no matching documentation for the IPMI interface. The web-interface works but the logic is mostly inside the AcsWeb webserver binary.
There's a cyc_ipmicmd binary but that one doesn't offer any --help functionality to explain how to call it.
For future reference here's the missing man page:
cyc_ipmicmd(1) General Commands Manual cyc_ipmicmd(1) NAME cyc_ipmicmd - utility for power cycling servers via IPMI SYNOPSIS cyc_ipmicmd SERVER COMMAND DESCRIPTION The cyc_ipmicmd utility is a wrapper around /bin/ipmitool which allows to send IPMI power commands such as On, Off, Status and Cycle to configured devices. The server address as well as necessary authentication data is taken from /etc/IPMIServer.conf. CONFIG FILE FORMAT The /etc/IPMIServer.conf file contains the necessary data to successfully send IPMI commands to remote devices. Each line contains one remote server definition with the following colon separated fields: - Numerical server ID (starting at 1) - IP address - Authentication Type (none, password, md2, md5) - Access Level (user, operator, admin) - Username - Password - Alias (human readable name) An example line might look as follows: 1:192.168.0.1:password:operator:user:pass:Example Server: SERVER parameter The server parameter is the numerical server ID taken from the first field of the configuration file. COMMAND parameter The command parameter is numerical code which specifies which command is being sent to the remote IPMI device. 0 Off Poweroff the server 1 On Poweron the server 2 Status Reportpower status 3 Cycle Powercycle the server EXAMPLES: Powercycle the first server: cyc_ipmicmd 1 3 AUTHOR: Andreas Thienemann
I'm trying to add TPM support to the initrd images on Fedora 20. The idea is that the cryptokeys for the harddrive encryption are only handed out to cryptsetup as long as the whole bootchain is unmodified.
The tpm-luks package seems to be able to do the trick but needs to be adapted to the current boot procedure where systemd is part of the initial ramdisk image.
In order to actually observe what's going on inside the initramfs dracut already offers a lot of functionality which can be activated with the following dracut debugging command line arguments.
Especially the shell is a good helper but I was looking for something which allows me to poke around while systemd is presenting the user with a password prompt. For this I wanted a shell into the initramfs which allows for out-of-band access. A simple sh started in the background with input and output redirected to /dev/ttyS1 should do the trick I decided.
A nice feature of dracut is that it allows to include arbitrary files into the initramfs through thee dracut injection feature. This way a new systemd service file can be added which will take care of starting the serial shell:
[Unit] Description=Debugshell on ttyS1 [Service] ExecStart=/bin/sh -c '/bin/sh < /dev/ttyS1 > /dev/ttyS1 2>&1'
To make it all work, a dracut directory tree needs to be created and the appropriate symlinks be dropped to make systemd fire up the shell:
mkdir -p rd.live.overlay/etc/systemd/system/cryptsetup.target.wants cat << EOF > rd.live.overlay/etc/systemd/system/debugshell.service [Unit] Description=Debugshell on ttyS1 [Service] ExecStart=/bin/sh -c '/bin/sh < /dev/ttyS1 > /dev/ttyS1 2>&1' EOF ln -s ../debugshell.service rd.live.overlay/etc/systemd/system/cryptsetup.target.wants/debugshell.service dracut -f --include rd.live.overlay / /boot/initramfs-$(uname -r).imgAnd that's it. On the next boot a serial shell is available on ttyS1 while the crypto password is asked for on the main screen.
dss_cli is a small command line program written in Python which can serve as the base for automating tasks on the Open-E Data Storage Server. A sysadmin can use it to control regular maintainance from the shell instead of having to log into the web-interface through a browser.
It can access the existing API via SSH and provides missing functionality by interfacing with the web-server on the DSS appliance. It is using both mechanize and Beautiful Soup to make it resiliant to changes in the webinterface. While it was originally written on a DSS v6, initial tests showed that it mostly works on the DSS v7 release as well.
The "Data Storage Server" from Open-E is a linux based software appliance. After installing the software on a server, the server can then offer NAS and iSCSI storage to attached clients and is manageable through a web-interface.
One interesting feature of the appliance is, that it does offer failover for both iSCSI exported block devices as well as for NFS shared folders, something which makes it very interesting for Bawue.Net. The active/passive failover pair should give us better availability for maintenance as one half of the failover pair can be taken down for maintenance without affecting the virtual machines using the filer as a storage.
During testing of the DSS v6 system we did notice however a certain lack of functionality: The webinterface is great to manage the servers, create volumes, export these and set them up for replication. But using the webinterface is a manual process full of repetitive steps while the tasks at hand call for automation to reduce operator errors and to allow configuration through tools like puppet.
In order to help with automation, the DSS appliance offers an API/CLI access via ssh: Generate a key, connect to the server via ssh and pass some commands:
$ ssh -p 22223 -i filer1.key -l api 192.168.2.220 get_driveslist -v Unit Size(GB) Serial Number Status S001 1862.64 4096e40371761527 vg,arc_vol_000 S002 279.40 4096e41532029185 vg,arc_vol_001Unfortunately, the API is incomplete: It does allow for a lot of automation tasks, it does not export all the functionality to create working failover volumes and destroy them again. If there are plans to use the DSS filer as a storage backend for any kind of automated creation of virtualized servers these functions are sorely needed to prevent the need for manual interaction.
In order to address this lack of functionality, I wrote dss_cli, a command line client aimed at owners and administrators of DSS appliances in order to support all daily administration tasks needed on these filers.
Provide a second tool to combine common steps for creation of iSCSI and NAS targets in a cluster.
Otherwise I am also taking nominations for needed functionality.
The current code is available on GitHub::ixs/dss_cli and is published under the GPLv2. Preqrequisites to running the dss_cli command is a recent Python installation with the Paramiko module for SSH connectivity and mechanize and Beautiful Soup for the web-scraping functionality.
Installation is simple: Download the latest code, unzip it in a new directory and edit config.ini to reflect your environment.
The [failovergroup] section contains your failover pairs, one group per line.
The example below defines one failovergroup called main, containing the dss1 and the dss2 filer.
The [dss1] and [dss2] section define their address, their admin passwords, the ssh_key needed for the API functionality and whether they are the primary or the secondary host in the failover group.
[failovergroups] main = dss1 dss2 [dss1] address = 192.168.220.1 password = admin sshkey = dss1_api.key mode = primary [dss2] address = 192.168.220.2 password = admin sshkey = dss2_api.key mode = secondary
./dss_cli --help Usage: dss_cli [options]Command Line Interface to interact with an Open-E DSS Storage Server Options: -h, --help show this help message and exit -f FILE, --file=FILE Configuration file to use -l, --list List all commands available -g, --failovergroup List all configured failover groups -d, --debug Use --list to get a list of all supported commands. Each command should support the --help parameter to get a list of accepted arguments.
Running ./dss-cli -l dss1 does give a list of all commands supported on that device:
$ ./dss_cli -l filer1 build - Lists and sets default build. check_mk_agent - Returns information from check_mk monitor create_iscsilv - Creates a logical iSCSI Volume. create_naslv - Creates a logical NAS volume. date - Sets time and date; please use the following format: yyyy-mm-dd hh:mm:ss failover - This function allows you to stop, run or change the operation mode for the given server. failover_task - Manage a failover task get_TXbytes - Returns total number of bytes transmitted for the given interface. get_TXpackets - Returns total number of packets transmitted for the given interface. get_driveslist - Fetches a list of drives. get_hwstatus - Returns information from system hardware monitor. get_memorystatus - Fetches memory status. get_nichealth - Fetches the status of the given Network Interface Card. get_nicslist - Lists Network Interface Cards. get_raidstatus - Returns information about RAID. help - Lists all available methods iscsi_target_access - Configure Target IP access iscsi_target_assign - Assign lv with given name to existing iSCSI target. iscsi_target_create - Creates a new iSCSI target. iscsi_target_list - Lists iSCSI targets (syntax: alias;name). iscsi_target_remove - Remove an existing iSCSI target iscsi_target_restart - Restart iSCSI target service. iscsi_target_sessions - Shows and manages iSCSI target sessions. iscsi_target_status - Lists the parameters of the selected target. iscsi_target_unassign - Unassign from given iSCSI target lvname. lv_remove - Remove a logical volume nas_settings_http - Enables and disables access to shares via HTTP. nas_share_access_afp - Modifies AFP share access. nas_share_access_ftp - Enables and disables access to shares via FTP nas_share_access_http - Enables and disables access to shares via HTTP. nas_share_access_nfs - Enables and disables access to the given share via NFS. nas_share_access_smb - Modifies SMB/AFP share access. nas_share_create - Create share on specified volume. nas_share_details - Display detailed configuration of share nas_share_edit - Changes share location or comment. nas_share_groups - Groups manipulation functions. nas_share_list - Lists shares nas_share_remove - Removes the given share. nas_share_toggle_smb - Enable or disable SMB support for a share nas_share_users - Users manipulation functions. nas_user_add - Create user in the system. nas_user_groups - Adding and removing users to groups. nas_user_remove - Removes the given user from the system. nas_user_rename - Rename NAS user. ntp - Fetches the time and date from an NTP server. reboot - Reboots the system. set_nic - Configures Network Interface Cards. set_powersettings - Sets the power button action scheme. shutdown - Shuts the system down. snapshot_task - Starts and stops snapshots. task - This function allows you to start task. test - Generates an example of a help message. unit_manager - Creates new volume group or adds unit(s) to existing volume group. update - Initiates and checks the status of software update. version - Fetches the software version. volume_group_status - Lists Volume Groups. volume_iscsi_remove - Removes a logical iSCSI volume volume_replication - Adds and removes replication to volume. volume_replication_mode - Set volume replication mode to source or destination volume_replication_remove - Removes replication from Volume volume_replication_task_create - Create a volume replication task volume_replication_task_remove - Remove a replication task volume_replication_task_status - Status of a replication task volume_replication_task_stop - Stop a replication task volume_status - Displays storage info.
The following commands would serve to create a failover iSCSI volume on dss1 and dss2:
Create the logical volumes on both filers as part of the arc_vol_000 volume group. Command line arguments are create_iscsilv <vg_name> <size> blockio
The size argument is specified in 32MB blocks. 150GB * 1024 / 32 = 4800.
$ ./dss_cli filer1 create_iscsilv arc_vol_000 4800 blockio lvarc_vol_00000 $ ./dss_cli filer2 create_iscsilv arc_vol_000 4800 blockio lvarc_vol_00000
Enable volume replication for both logical volumes on both filers and set the logical volume on filer2 to be a secondary volume/replication destination.
$ ./dss_cli filer1 volume_replication add lvarc_vol_00000 $ ./dss_cli filer2 volume_replication add lvarc_vol_00000 $ ./dss_cli filer2 volume_replication_mode lvarc_vol_00000 secondary
Create, start and monitor the replication task on the primary filer and give it 80MBps bandwidth for initial synchronisation.
$ ./dss_cli filer1 volume_replication_task_create lvarc_vol_00000 lvarc_vol_00000 failover_iscsi_target0 80 $ ./dss_cli filer1 task --start VREP failover_iscsi_target0 $ ./dss_cli filer1 volume_replication_task_status failover_iscsi_target0
Create the iSCSI targets on both systems.
$ ./dss_cli filer1 iscsi_target_create target0 $ ./dss_cli filer2 iscsi_target_create target0
Assign the created volume to the just created iSCSI target on both systems. The server will report back with a randomly generated SCSI id for the LUN. Make sure to pass this one when assigning the volume on the secondary system. These ids need to be the same.
$ ./dss_cli filer1 iscsi_target_assign target0 lvarc_vol_00000 lvarc_vol_00000:target0:0:wt:Dgp5VLni08UGb5W5 $ ./dss_cli filer2 iscsi_target_assign target0 lvarc_vol_00000 -s Dgp5VLni08UGb5W5 lvarc_vol_00000:target0:0:wt:Dgp5VLni08UGb5W5
Add the replication task to the list of active failover tasks and make sure that failover services are started.
$ ./dss_cli filer1 failover_task failover_iscsi_target0 enable $ ./dss_cli filer1 failover --start
Es passiert regelmässiger, dass ich unterwegs bin und dort ein Telekom Hotspot vorhanden ist. Aktuell ist dies z.B. im Novotel Karlsruhe der Fall.
Telekom Hotspots haben wie die meisten öffentlichen Hotspots ein sogenantes Captive Portal durch das die Authentifizierung stattfindet.
Ich bin glücklicher Besitzer einer Telekom Hotspot Flatrate und möchte diesen Account gerne verwenden. Allerdings ist die regelmässig wiederkehrende Authentifizierung sehr nervig. Obwohl der Browser Login und Passwort nicht speichert wäre es dennoch schön wenn diese Anmeldung automatisch geschehen könnte.
Gesagt, getan. Hier ein kleines Python Script dass genau diese Aufgabe übernimmt:
As I am travelling quite a bit I am often in the situation that I have a hotel room with a network cable and Internet access, but I have a notebook and a smart phone with me and the only device with an Ethernet connector is the notebook.
When I saw the ASUS WL-330N3G wireless mobile router I immediately bought the gadget. It's a small and portable router with 3 main uses for me:
When playing around with the router you can brick the device (e.g. uploading incorrectly rebuilt firmware from the GPL sources). If this happens, the device will not boot correctly any more but will be flashing it's power LED and possibly the network activity LED as well. The device can be put into rescue mode however where it will take a tftp uploaded firmware file and flash it:
At this point the device has recovered and you'll be able to log in again...
$ while true; do for i in '|' '/' '-' '\'; do echo -n $i; sleep 0.25; echo -ne '\b'; done; doneThis will create a little ascii spinner and keep a line spinning until you press CTRL-C.
Christoph Wickert already wrote a lot about FrOSCon 2011 so I do not have to add much. Thank god for that as I find blogging to be rather tedious lately...
Suffice to say the conference was great fun.
Even though I wasn't at FrOSCon for Fedora but for my employer Booking.com, who was one of the FrOSCon sponsors, I still managed to spend quite some time with the fellow Fedora people. I even got roped into providing a talk during the Fedora Activity Day.
As a topic I chose func, a remote execution framework we have been using quite successfully at Booking for automating a lot of processes.
Reading the fedora planet I got the impression that the new Fedora 15 alpha release must suck.
This impression is mostly based on the screenshots Nicu posted as well as the accompanying, vicious review.
Having seen these, I naturally had to try the new F15 release for myself to see what this is all about.
Having booted it up in a virtual machine I am now ready to proclaim that Fedora 15 does not suck. The system greets me the same way prior releases did and the only noticable difference is a different release name and newer kernel release.
However, in the few minutes I spent with the new release I have to say that I already found two bugs:
After switching to the graphical login screen with gdm3, the screen becomes garbled. Suddenly the background is full of scanlines reminding me of the old days when I didn't had the correct modeline in the /etc/X11/X11.conf file.
I was assured however on IRC, that my hardware is not broken and this is the normal design for the Alpha release and the final one will not destroy my display. Thank god for that.
The other bug is that after ignoring the garbled screen and actually logging in, the desktop has become totally broken and hideous. Black and grey bars are alternating and hurting my eyes, functionality is missing, I have to switch constantly to the command line to change settings etc...
Again however the friendly people on the IRC channel came to the rescue and informed me that this is a known bug (tracked in the ohh so aptly named F15GnomeFAIL tracker) and it is actually not a software bug but human error.
It seems I just picked the wrong iso image thinking that the Desktop-ISO is actually for the Desktop. It looks like this is a common mistake and the real Desktop Spin is further down on the Download page. Silly me, we obviously have to better educate our Target Audience to pick the right image.
While I am actually very interested in seeing what the Gnome3 shell actually has to offer, this is not the release to do so. I seriously ask myself if this is the most unfinished and broken-by-default Fedora release there ever was. The Go/No-Go meeting should have just taken the hard decision and delayed the F15 release by 6 months. Maybe then this would look more like a release and less than a trainwreck.
I am basically disgusted at this point.
Snom is the maker of pretty decent VoIP phones running Linux. I have had a Snom 360 for some time now and am reasonably happy with it.
The Snom phones do support SNMP but their SNMP daemon is severly limited. It only supports GETs on a small number of OIDs, doesn't support WALK and standard MIBs like the system-MIB are not supported. The Snom Wiki has a list of the supported OIDs and a description how to enable SNMP on the phones.
The limited support makes autodetection by network management systems or MRTG's cfgmaker fail. In order to chart this data, a manually created template is therefore needed.
Some other values worth charting could be CPU load and free memory or the number of registered extensions. This could be useful for tracking down errors. Unfortunately, mrtg is unable to chart this correctly out of the box and needs some help converting the data.
This is therefore left as an excercise to the reader.
The proprietary version of Oracle VirtualBox does offer USB support.
This means that the guest operating system can access USB devices plugged into the host system.
This USB passthrough feature is also available with many other desktop virtualization solutions, e.g. KVM and Qemu. Nevertheless it seems VirtualBox is favoured by a large number of users who are installing VirtualBox only to find that they cannot actually make their USB devices visible to the guest operating system. The common problem seems to be that they checkboxes next to the devices are grayed out, preventing the user from marking them to be added to the guest.
There are a large number of forum articles and blog posts available which all claim to have a solution to the issue. Very often the suggested solution is to change the mount options for /proc/bus/usb in fstab or add an appropriate entry. Sometimes it is suggested to mount usbdevfs to /sys/bus/usb/drivers. Some report success by editing certain udev rules so that files the in the procfs belong to the user executing the VirtualBox binary.
All these solutions have one thing in common:
They are all wrong!
The fact that they are mindlessly repeated by posters in a large number of user-centric web forums does not help at all.
It is still wrong!
I said it before but it still is true: Web forums are full of cargo-cult users: No idea what they are doing but trying and talking about it in the hope that it will achieve something.
The right solution is actually very simple. All that is needed is to add the user running VirtualBox to the vboxusers group:
[root@minos ~]# usermod -a -G vboxusers athienemann [root@minos ~]# groups athienemann athienemann : athienemann vboxusers [root@minos ~]#
That's all. The user athienemann now can add and remove USB devices from VirtualBox guests.
Wasn't that easy? No fiddling with udev or fstab needed.
Mein geschätzter Kollege Kris schreibt etwas über Unix und Standards. Neben der Tatsache dass das schöne an Standards ist, dass es so viele gibt und man sich einen aussuchen kann, erwähnte Kris auch die Befürchtung dass BTRFS möglicherweise relizensiert werden könnte.
Die Gefahrt dass BTRFS relizensiert wird besteht nicht.
Zwar wurde die BTRFS Entwicklung bzw. der BTRFS-Haupt-Entwickler durch Oracle finanziert, der Code selber befindet sich jedoch mittlerweile im Upstream-Tree des Kernels. Damit gilt die GPL2 und diese Lizensierung kann nachträglich nicht geändert werden.In diesem Fall kann die relizensierte Version als Fork angesehen werden und die bekannten Probleme kommen dann zur Geltung.
Der Spruch mit Eiche und Sau dürfte in diesem Fall nicht unangebracht sein.
My first day at LinuxTag was rather uneventful as I only arrived in Berlin during the evening and thus couldn't attend the fair during the day. In short, the day looked as follows:
Took the car to Berlin, went directly to the hotel, handed the car off, dropped off the luggage and went for Dinner with the other Fedora guys waiting in front of the hotel.
Dinner was at a steakhouse a few minutes from the hotel and was enjoyable. The steak was nice and the opportunity to catch up on things with Andreas, Christoph, Fabian, Gerold, Robert, Sandro and Thomas was even better.
Afterwards we returned to the Hotel and spent a few hours in the lobby, chatting some more with the other Fedora people sharing the same hotel. As the night was still young we moved outside to a few tables in front of the hotel, enjoying the warm summer night and exchanging some more gossip and ranting about the things in Fedora which made us unhappy.
After all, a very nice first day where I could catch up with old friends and had the ability to make some new acquaintances.
I enjoy you immensly, it's been great meting old friends and making some new ones. Furthermore you are perfect for catching up with some former colleagues, other developers and for talking about lingering issues in a much more sensible setting than a mailing list filled with people with too much time for pointless bickering.
Ignore the people claiming that you're at the wrong time, the wrong location or the wrong anything. Sure, you're not always next door and sometimes you're even at the other end of the world. I won't be attending you in such cases, but there's always a FUDCon closer by which is worth it. Ignore the haters, they are just cramping your style.
But talking about style, I would really, really pretty please with sugar on top have you offering a more relaxed setting for conducting chats between a small group of people or just one-on-one talks. You have something called a lounge, but it's not really conductive for staying longer, the chairs are horrible. And your little brother FUDPub is too wild. No time there.
So please FUDCon, improve your style a bit and make your "lounge" a real lounge. I'll love you for that even more.
I'm thinking about something like that here:
Your biggest fan