Elsewhere

Michal Čihař: Weekly phpMyAdmin contributions 2016-W05

Planet Debian - Tue, 09/02/2016 - 12:00

Last week was really focused on code cleanups. The biggest change was removal of PmaAbsoluteUri configuration directive, which has caused quite some pain in past and is not really needed these days (when browsers support relative paths in the Location HTTP header).

This lead to cleanup in other parts as well - support for dead Mozilla Prism is gone, used HTTPS for OpenStreetMap tiles (the map layer now works on HTTPS as well), removed ForceSSL configuration directive as this is something what really needs to be handled at web server level. To improve test coverage, several tests no longer require runkit as the header() call is wrapped within Response class and can be overridden for testing without using runkit.

The list of handled issues is not that impressive this week:

Filed under: English phpMyAdmin | 0 comments

Categories: Elsewhere

Mike Gabriel: Résumé of our Edu Workshop in Kiel (26th - 29th January)

Planet Debian - Tue, 09/02/2016 - 10:50

In the last week of January, the project IT-Zukunft Schule (Logo EDV-Systeme GmbH and DAS-NETZWERKTEAM) had visitors from Norway: Klaus Ade Johnstad and Linnea Skogtvedt from LinuxAvdelingen [1] came by for exchanging insights, knowledge, technology, stories regarding IT services at school in Norway and Nothern Germany.

This was our schedule...

Tuesday
  • 3pm – Arrival of Klaus Ade and Linnea, meet up at LOGO with coffee and cake
  • 4pm – Planning the workshop, coming up with an agenda for the next two days (Klaus Ade, Andreas, Mike)
  • 5pm – Preparing OPSI demo sites (Mike, Linnea)
  • 8pm – Grünkohl and Rotkohl and ... at Traum GmbH, Kiel (Klaus Ade, Linnea, Andreas, Mike)
Wednesday
  • 8.30am – more work on the OPSI demo site (Mike, Linnea)
  • 10am – pfSense (esp. captive portal functionality), backup solutions (Klaus Ade, all)
  • 11am – ITZkS overlay packages, basic principles of Debian packaging (Mike, special guests: Torsten, Lucian, Benni)
  • 12am-2pm – lunch break
  • 2pm – OPSI demonstration, discussion, foundation of the OpsiPackages project [2] (Mike)
  • 4pm – Puppet (Linnea)
  • 7pm – dinner time (eating in, Thai fast food :-) )
  • 20pm – Sepiida hacking (Mike, Linnea), customer care (Andreas, Klaus Ade)
  • 22:30pm – zZzZzZ time...
Thursday

read more

Categories: Elsewhere

Microserve: Caching beyond the norm in Drupal 7

Planet Drupal - Tue, 09/02/2016 - 10:19
Caching beyond the norm in Drupal 7Feb 9th 2016

When developing in a drupal centric environment there are two general methods used to cache information on the system in modules, these can be used to persist while a page is loading using drupal static or for a longer periods using cache set and cache get.

I have used some other simple and alternative methods, and from reading notes before the drupal_static function declaration in bootstrap.inc; ways of getting even more efficient caching.

First I’ll address drupal static; it’s explained very neatly on this Lullabot article.

This is not necessarily always required. If you have a simple function in your code that you want to remember, a setting and speed is a must, you can just use a static variable.

function get_a_value($value_name) { static $function_settings = array(); if (!isset($function_settings[$value_name])) { //get variable from database and set it to $fetched_value $function_settings['$value_name'] = $fetched_value; } else { return $function_settings[$value_name]; } }

The static variable $function_settings stays persistent throughout the execution of your page, and the caching stays localised to your function / module.

Another way to do something similar to above, but to include the drupal_static function, would be to do an advanced drupal_static pattern (this is mentioned in the drupal_static notes).

function user_access($string, $account = NULL) { // Use the advanced drupal_static() pattern, since this is called very often. static $drupal_static_fast; if (!isset($drupal_static_fast)) { $drupal_static_fast['perm'] = &drupal_static(__FUNCTION__); } $perm = &$drupal_static_fast['perm']; //... }

This is taken directly from the notes. Here we assign a local static variable as in the previous example but if the local static variable is not set, we assign the local static variable to drupal_static. Now other functions and code outside of the function can call on drupal_static_reset and reset the locally declared static variable, but will still retain the efficiency of having the static variable locally as in the previous example.

The last method I would like to approach is by using a cache in an object:

class SomeClass { /** * * @var array */ protected $localCache = array(); public function getData($cid) { if ($data = $this->getCache($cid)) { return $data; } //nothing set //do time intensive task here and set to data $this->cache($cid, $data); return $data; } /** * * @param type $cid * @param type $data */ protected function cache($cid, $data) { $this->setLocalCache($cid, $data); cache_set($cid, $data, 'cache', strtotime('+7 days', time())); } protected function getCache($cid) { if ($data = $this->getLocalCache($cid)) { return $data; } if ($cache = cache_get($cid)) { return $cache->data; } return FALSE; } /** * * @param any $cid * @param any $data */ protected function setLocalCache($cid, $data) { $this->localCache[$cid] = $data; } /** * * @param any $cid * @return any */ protected function getLocalCache($cid) { return isset($this->localCache[$cid]) ? $this->localCache[$cid] : FALSE; } }

In this example, I do all the local caching within the object but if needs be, I will retrieve and save to the system cache if the required data is not saved locally. One thing I have omitted is methods to clear the local cache. This caching this essentially using a local property.

If you wanted to clear the cache externally, you could create a public method or a static method.

So that about wraps this one up. Have you used any different methods? Can it be done better? Tell me what you think in the comment section below.

Written by: Darren Whittington, Senior Developer

Microserve is a Drupal Agency based in Bristol, UK. We specialise in Drupal Development, Drupal Site Audits and Health Checks, and Drupal Support and Maintenance. Contact us for for further information.

Categories: Elsewhere

Deeson: Drupal Focal Point Module: Making the most of your images

Planet Drupal - Tue, 09/02/2016 - 10:15

Focal point is a Drupal module that allows site administrators to select an important portion of an image to focus on.

It’s similar in many ways to the Image field focus module. But rather than giving a square box with crosshairs for focusing and another for cropping (which you can only do inside the focus area and can be quite confusing), focal point allows you to select a single point on the image to focus on. It is also fully compatible with the Media module.

User experience

Let's take a look at focal point from an administrator's perspective. The user can click on the image at any point which adds an icon over that particular area, representing the chosen focal point (see below).

From this, the administrator can then select the “Image preview” link below the image which will display a page with both the original image and how the image will look with the different image styles.

As you can see below, the image has now been focused upon the parrot on the right.

Setup and configuration

Firstly, you need to download and enable the focal point module (https://www.drupal.org/project/focal_point).

Upon enabling the module you will find a new image style called “Focal Point Preview”. This is used for the admin page and is the default preview style for setting the focal point. It rescales the image width to 250px with upscaling allowed.

You will also have two new image effects available for cropping “Focal Point Crop” and “Focal Point Scale And Crop” within the drupal image styles at admin/config/media/image-styles.

These both crop down to the point to which the user has selected on the image, and ensure that the chosen focal point will not be cropped out of the image.

Now you can create a new image style with one of these image effects, and then apply this image style to an image field within the manage display page of your content type. The images will then crop to the selection the user has chosen.

Media

To enable the compatibility with the media module, you should ensure that the “Media module image fields” setting at admin/config/media/focal_point is enabled.

Then, after adding an image via a field using the media browser widget, another step is provided in the media browser overlay. You can now add a focal point as you would in a standard image field.

You can also edit previously uploaded images to set an individual focal point.

Categories: Elsewhere

Orestis Ioannou: Using debsources API to determine the license of foo.bar

Planet Debian - Tue, 09/02/2016 - 09:45

Following up on the hack of Matthieu - A one-liner to catch'em all! - and the recent features of Debsources I got the idea to modify a bit the one liner in order to retrieve the license of foo.bar.

The script will calculate the SHA256 hash of the file and then query the Debsources API in order to retrieve the license of that particular file.

Save the following in a file as license-of and add it in your $PATH

#!/bin/bash function license-of { readlink -f $1 | xargs dpkg-query --search | awk -F ": " '{print $1}' | xargs apt-cache showsrc | grep-dctrl -s 'Package' -n '' | awk -v sha="$(sha256sum $1 | awk '{ print $1 }')" -F " " '{print "https://sources.debian.net/copyright/api/sha256/?checksum="sha"&packagename="$1""}' | xargs curl -sS } CMD="$1" license-of ${CMD}

Then you can try something like:

license-of /usr/lib/python2.7/dist-packages/pip/exceptions.py Notes:
  • if the checksum is not found in the DB (compiled file, modified file, not part of any package) this will fail
  • if the debian/copyright file of the specific package is not machine readable then you are out of luck!
  • if there are more than 1 versions of the package you will get all the available information. If you want to get just testing then add "&suite=testing" after the &packagename="$1" in the debsources link.
Categories: Elsewhere

Ingo Juergensmann: rpcbind listening on all interfaces

Planet Debian - Mon, 08/02/2016 - 23:20

Currently I'm testing GlusterFS as a replicating network filesystem. GlusterFS depends on rpcbind package. No problem with that, but I usually want to have the services that run on my machines to only listen on those addresses/interfaces that are needed to fulfill the task. This is especially important, because rpcbind can be abused by remote attackers for rpc amplification attacks (dDoS). So, the rpcbind man page states: 

-h : Specify specific IP addresses to bind to for UDP requests. This option may be specified multiple times and is typically necessary when running on a multi-homed host. If no -h option is specified, rpcbind will bind to INADDR_ANY, which could lead to problems on a multi-homed host due to rpcbind returning a UDP packet from a different IP address than it was sent to. Note that when specifying IP addresses with -h, rpcbind will automatically add 127.0.0.1 and if IPv6 is enabled, ::1 to the list.

Ok, although there is neither a /etc/default/rpcbind.conf nor a /etc/rpcbind.conf nor a sample-rpcbind.conf under /usr/share/doc/rpcbind, some quick websearch revealed a sample config file. I'm using this one: 

# /etc/init.d/rpcbind
OPTIONS=""

# Cause rpcbind to do a "warm start" utilizing a state file (default)
# OPTIONS="-w "

# Uncomment the following line to restrict rpcbind to localhost only for UDP requests
OPTIONS="${OPTIONS} -h 192.168.1.254"
#127.0.0.1 -h ::1"

# Uncomment the following line to enable libwrap TCP-Wrapper connection logging
OPTIONS="${OPTIONS} -l "

As you can see, I want to bind to 192.168.1.254. After a /etc/init.d/rpcbind restart verifying that everything works as desired with netstat is showing...

tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 0 2084266 30777/rpcbind
tcp6 0 0 :::111 :::* LISTEN 0 2084272 30777/rpcbind
udp 0 0 0.0.0.0:848 0.0.0.0:* 0 2084265 30777/rpcbind
udp 0 0 192.168.1.254:111 0.0.0.0:* 0 2084264 30777/rpcbind
udp 0 0 127.0.0.1:111 0.0.0.0:* 0 2084260 30777/rpcbind
udp6 0 0 :::848 :::* 0 2084271 30777/rpcbind
udp6 0 0 ::1:111 :::* 0 2084267 30777/rpcbind

Whoooops! Although I've specified that rpcbind should only listen to 192.168.1.254 (and localhost as described by the man page) rpcbind is still listening on all addresses. Quick check if the process is using the correct options: 

root     30777  0.0  0.0  37228  2360 ?        Ss   16:11   0:00 /sbin/rpcbind -h 192.168.1.254 -l

Hmmm, yes, -h 192.168.1.254 is specified. Ok, something is going wrong here...

According to an entry in Ubuntus Launchpad I'm not the only one that experienced this problem. However this Launchpad entry mentioned that upstream seems to have a fix in version 0.2.3, but I experienced the same behaviour in stable as well as in unstable, where the package version is 0.2.3-0.2. Apparently the problem still exists in Debian unstable.

I'm somewhat undecided whether to file a normal bug against rpcbind or if I should label it as a security bug, because it opens a service to the public that can be abused for amplification attacks, although you might have configured rpcbind to just listen on internal addresses.

Kategorie: DebianTags: DebianSoftwareNetworkBug 
Categories: Elsewhere

Niels Thykier: Performance tuning of lintian, take 3

Planet Debian - Mon, 08/02/2016 - 23:19

About 7 months ago, I wrote about we had improved Lintian’s performance. In 2.5.41, we are doing another memory reduction, where we primarily reduce the memory consumption of data about ELF binaries.  Like previously, memory reductions follows the “less is more” pattern.

My initial test subject was linux-image-4.4.0-trunk-rt-686-pae_4.4-1~exp1_i386.deb. It had a somewhat unique property that the ELF data made up a little over half the cache.

  • We do away with a lot of unnecessary default values [f4c57bb, 470875f]
    • That removed about ~3MB (out of 10.56MB) of that ELF data cache
  • Discard section information we do not use [3fd98d9]
    • This reduced the ELF data cache to 2MB (down from the 7MB).
  • Then we stop caching the output of file(1) twice [7c2bee4]
    • While a fairly modest reduction (only 0.80MB out of 16MB total), it also affects packages without ELF binaries.

At this point, we had reduced the total memory usage from 18.35MB to 8.92MB (the ELF data going from 10.56MB to 1.98MB)[1]. At this point, I figured that I was happy with the improvement and discarded my test subject.

While impressive, the test subject was unsurprisingly a special case.  The improvement in “regular” packages[2] (with ELF binaries) were closer to 8% in total.  Not being satisfied with that, I pulled one more trick.

  • Keep only “UND” and “.text” symbols [2b21621]
    • This brought coreutils (just the lone deb) another 10% memory reduction in total.

In the grand total, coreutils 8.24-1 amd64 went from 4.09MB to 3.48MB.  The ELF data cache went from 3.38MB to 2.84MB.  Similarly, libreoffice/4.2.5-1 (including its ~170 binaries) has also seen a 8.5% reduction in total cache size[3] and is now down to 260.48MB (from 284.83MB).

 

[1] If you are wondering why I in 3fd98d9 wrote “The total “cache” memory usage is approaching 1/3 of the original for that package”, then you are not alone.  I am not sure myself any more, but it seems obviously wrong.

[2] FTR: The sample size of “regular packages” is 2 in this case.  Of which one of them being coreutils…

[3] Admittedly, since “take 2” and not since 2.5.40.2 like the rest.


Filed under: Debian, Lintian
Categories: Elsewhere

Pages

Subscribe to jfhovinne aggregator - Elsewhere