sexta-feira, 3 de setembro de 2010

Airport wireless nonsense

In a world where flights cost from 60 EUR, where you can do web and sms based check-ins, where broadband is cheap and works well, where network electronics costs next to nothing, where smartphones and netbooks are standard and where 3G data roaming costs arms and legs ... which stubborn old-fashioned airport would try to charge passengers for wifi?

Strangely the answer is: most of them.

Weird as it seems major airports in Oslo, Stockholm, Hamburg, Lisbon, etc... want you to pay for the few megabytes of wifi connectivity you're able to use between flight connections. Others provide clumsy web kiosks to be fed with Euro coins. This is, or should be, a major embarrassment for any developed country as it represents the kind of impolite reception one does not expect from any other service. Speaking for mine: I feel embarrassed. But the problem is global, and deserves a bit of reflection.

For example, what would we think if airports started charging 1 Eur for the usage of luggage carts? Not that expensive but certainly very rude. What if we had to fill a form to open a water tap? Would be surely very inconvenient. Neither of these two situations would be acceptable, by European standards, even if being potentially profitable. That's because we accept certain implicit rules on the limits of what can be capitalized per unit of consumption. The costs of water and power are part of the average running costs of an airport, as they should be. So is the cost of gas, used for heating. But still, the water pressure, voltage and temperature must be kept at the right levels.


Why not the Internet then? Internet access is nowadays as standard as electrical power or running water. That's as everyone should see it. That's what the current generation of consumers expect. Why shouldn't we be able to answer a couple of emails or read some online news while waiting for a flight? Sounds a little harsh not to allow wifi access inside a large and professionally managed structure such as an airport, given the low cost of maintaining such a service. This is not only a matter of price, but also a mixture of convenience and politeness. No passenger wants to spend 10 of his 30 minutes of flight transfer figuring out how to use his credit card for spending a couple of Euros on yet another silly access point service.

So in the end I guess few people end up using these services. Few Euros are spent, few Euros are earned, some bits of work are delayed and a fast growing number of IT capable travelers gets deeply annoyed.

The situation, as it is, doesn't seem interesting to any of the parties: the passenger either doesn't use the service or must go through annoyances to pay for it, the airport doesn't look good in the picture and the service provider... well let's just say that no brand got more sticky in my brain than Telia Sonera in the last days. But that's the kind of brand awareness that wouldn't make their marketing department any happy.

Security may be an issue. Network managers running open networks can surely run into problems if their “anonymous users” are misbehaving on the Internet. However, authentication via First Name, Last Name and Ticket Number must be trivial to implement and enough to ensure that wifi enabled passengers can be identified before connecting.

domingo, 4 de julho de 2010

Adeus Microsoft, Olá bom senso

Em plena crise económica João Paulo Girbal (JPG), ex-presidente da Microsoft Portugal, fez declarações ao Expresso. As declarações, no contexto de um artigo sobre Concorrência, são do mais elementar bom senso e praticamente à prova de crítica. São feitas na figura de representante de uma associação de fabricantes de produtos de marca (a que julgo se contraporem os produtos de marca branca ou marcas associadas a grandes superfícies) que aparentemente se sentem esmagados pela pressão dos preços nas superfícies de venda ao público.

Uma vez que defende a intervenção da tutela na promoção de “desenvolvimento sustentável e criação de valor local” e está preocupado com problemas de concorrência e situações de “produto único”, seria interessante saber o que pensa João Paulo Girbal sobre o acoplamento forçado entre equipamentos e sistemas operativos que a Microsoft tem promovido anos a fio com a cumplicidade de marcas como a Toshiba, HP, Sony, etc, sob a passividade e inacção da nossa Autoridade da Concorrência. Será ficção? Não é. Basta ver que no momento em a força do monopólio foi muito timidamente aliviada (projecto e-escolas apenas uma marca, a INSYS, tinha oferta Linux Caixa Mágica, porque todas as restante se opuseram) logo a oferta “alternativa” vendeu dezenas de milhares de unidades.


Isto para não relembrar o saga ODF / OOXML. Ou a fantochada multiplataforma do Silverlight com a pretensa implementação da Novell que está constantemente desactualizada. Tais situações certamente desagradam a JPG. É que a Microsoft tem perseguido, por todos os meios, precisamente aquilo que JPG actualmente não aprova. E, para satisfação da própria, a tutela não tutela e o consumidor nem sempre se apercebe.




quinta-feira, 1 de julho de 2010

PHP, FCGID and Apache - a confusion of upload related limits

There is a number of web hosting situations where PHP applications appear to misbehave during large upload operations. This may happen, for example, when dealing with attachments via webmail clients like roundcube or during the upload of files to document management applications.

Things get more difficult if we are talking about shared hosting on an apache + mod_fcgid + php environment, as there are several different parameters to be tuned in order for large uploads to work.

As far as we could see, there's a lot of people hitting different limits in their applications and looking for solutions, but no handy summary of where to make the necessary changes.

Architecture recap

Traditionally the PHP interpreter ran inside the apache process. Apache would load the PHP library (mod_php.so) and use it to parse the PHP based pages. Using a wrapper for the execution of PHP opens new possibilities. This is how the mod_fcgid developers see their approach to the problem:

mod_fcgid is a high performance alternative to mod_cgi or mod_cgid, which starts a sufficient number instances of the CGI program to handle concurrent requests, and these programs remain running to handle further incoming requests. It is favored by the PHP developers, for example, as a preferred alternative to running mod_php in-process, delivering very similar performance.

Not going into lengthy performance discussions (performance is cheap these days) we see see security as the main reason for adopting a mod_fcgi based architecture. In fact, it can be combined with SuExec to have each apache virtual host executing PHP as a different user. This is truly a life saver in terms of preventing damage and analyzing evidence from hacking attempts.

A detailed howto can be found here. A very nice tool for web hosting that integrates Apache, PHP and SuExec on RHEL/CentOS can be found here.

Time related parameters

The following PHP variables are involved:

max_execution_time - This sets the maximum CPU time in seconds a script is allowed to run

max_input_time - This sets the maximum time in seconds a script is allowed to parse input data, like POST, GET and file uploads

These variables can be tuned on the vhost specific php.ini file, eg

/home/DOMAINNAME/etc/php/php.ini

The exact path to each php.ini depends on your system.

The following Apache and mod_fcgid variables are also involved and should be appropriately set in the vhost directive in httpd.conf:

Timeout - Apache variable that is used for several different things, including "the length of time to wait for output from a CGI script". This defaults do 300 seconds and is used at apache level regardless of how PHP or other scripts are configured.

IPCCommTimeout / FcgidIOTimeout - This is specific to mod_fcgid and does NOT override any other settings. The default is 40 seconds

Notes: FcgidIOTimeout replaces the initial IPCCommTimeout for the same purpose. See the definition here. There is a bug related to mod_fcgid 2.2.x explained here.

Thus, if, from the client upstream bandwidth and the file sizes to support, the expected upload time is up to 10 minutes, you should set on php.ini

max_input_time = 600

and on the corresponding vhost on httpd.conf

IPCCommTimeout 600
Timeout 600
For example, if the client wants to upload 50MB over an ADSL line with an announced upstream rate of 1Mbps, the upload time in ideal conditions would be:

t = ( 50 * 1024 * 1024 * 8 ) / (1 * 1000 * 1000 * 0.8 ) ~ 524.29 s

In the previous formula 0.8 roughly accounts for the ADSL overhead and it is assumed that traffic on the ADSL "neighborhood" is low enough not to interfere with this file transfer.

As for max_execution_time it is harder to estimate as it's CPU time (ie, only counts when the process is actually running, not waiting for I/O) but you can start using the default which is 30. Depending on the total server load this may or may not have to be changed.

Size related parameters

The following PHP variables are involved:

upload_max_filesize - The maximum size of an uploaded file via PHP (uses HTTP upload)

post_max_size - Sets max size of post data allowed. This setting also affects file upload. To upload large files, this value must be larger than upload_max_filesize.

memory_limit - the memory limit for individual PHP scripts

Thus, to support files up to, say, 50M you should set something like:

post_max_size = 51M
upload_max_filesize = 50M

The memory_limit value is harder to estimate as it depends on what the script does with the file. For example for roundcube there was a popular bug regarding the amount of memory consumed by attachments (see here) but generally applications aren't so demanding.

The PHP documentation recomends memory_limit larger than post_max_size, so as a rule of thumb starting with 16 + post_max_size (16M is the default PHP value) should be enough. However, we think the documentation is wrong / outdated. To run things tight one can perfectly start with the default value of 16M and see if anything fails. Examining error_log will make clear if the script runs out of memory:

[warn] mod_fcgid: stderr: PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 4864 bytes)...

During our tests we realized that a simple file management web application could upload large files under the default PHP 16M memory_limit without any problems (tested on RHEL with php 5.1 - see similar comments here, here, and here).

Other parameters

The apache directive LimitRequestBody can also prevent large uploads. However, it defaults to 0 and is usually not present on httpd.cond, which means no limit is enforced by default.

References

max_execution_time
max_input_time
upload_max_filesize
post_max_size
memory_limit
Timeout (apache)
LimitRequestBody (apache)
FcgidIOTimeout (mod_fcgid)
PHP File Uploads
.

terça-feira, 29 de junho de 2010

Momento Zen

Momento Zen do dia, via Rui Gouveia. Com actores portugueses este filme teria um toque ainda mais realista.



.

quarta-feira, 14 de abril de 2010

Gente com fibra


Diz-se que a comunicação da malta das comunicações não é famosa. Pode ser verdade (ainda não foi desmentido) mas se calhar não é só isso que conta. Ao que se diz, toda a gente merece uma segunda oportunidade: "já que não é inteligente, ao menos seja bonita" ou "já que não sabe falar, que ao menos tenha bom aspecto". Será esse o caso? Este blog foi ver os enredos e concluiu que rolos maiores do que nas cabeças de helpdesk só mesmo no esparguete de fibra e cabos com que as telecomunicações de última geração adornam as melhores fachadas de Lisboa. E o resultado, naturalmente, não é bonito.

Segue-se uma mini reportagem fotográfica, no coração da capital.

Como destruir uma fachada cinquentista

Pormenor de execução


Ó fibra a quanto obrigas...


Pormenor de execução


Pormenor de execução


O verdadeiro "polvo" afinal era este


Nota: nunca esquecer o significado original da palavra "net"


A expressão de Engenheiro "reserved for future use" ganha aqui todo um novo significado


O verdadeiro cabo "co-axial"

quinta-feira, 18 de março de 2010

Comunicações em Português Suave - artigo de inverno

Na sequência do artigo de verão publicámos em parceria com o tek um novo artigo de opinião. Acompanha com tinto a 18ºC, queixo de cabra e (arrghhh) música de compasso de espera de call-center.

Votos de uma agradável leitura e um breve Inverno sem falhas de comunicação.

terça-feira, 2 de fevereiro de 2010

Firefox 3.6 na Caixa Mágica 12 e 14


Está disponível via Apt / Synaptic / Sofware Updater o Firefox 3.6 para a Caixa Mágica 12. Isto significa que os milhares de utilizadores das escolas (eescolas, Kit Tecnológico da Educação), individuais ou de empresas terão uma forma rápida e simples de fazer a actualização. Está igualmente disponível o Firefox 3.6 para Caixa Mágica 14 desde que o repositório das contribuições esteja activo (na CM14 o update oficial ainda é da série 3.0.0.x).

Como esta versão do Firefox representa um avanço considerável sobre as anteriores (performance, personas e estabilidade...) achamos o facto digno de menção.

upgrade via Synaptic na CM12

Firefox 3.6 com o tema Crystal Chrome