Ir para o conteúdo
ou

Thin-logo

Tela cheia Sugerir um artigo
Rss-feed

Grupo de Usuários Debian da Bahia - GUD/BA

6 de Dezembro de 2009 , por Desconhecido -

Seja bem vind@, se você é um debiano (um baiano que usa debian) faça parte de nossa comunidade!


Lançamento do Docker 1.8

24 de Agosto de 2015, por PSL-BA Feeds - 0sem comentários ainda

Não para de ter novidade no Docker! Mais um lançamento e muitas novidades.

Docker Content Trust

Agora é possínotaryvel assinar as imagens com sua chave privada antes de enviar para nuvem, com isso é possível validar as imagens e evitar que aconteçam fraudes no meio. Isso torna a solução como um todo bem mais segura.

Quer ler um pouco mais sobre o assunto? Veja esse link.

 

 

Docker Toolbox

Novo pacote de instalação para Mac OS X e Windows. Que conta com Docker client, Machine, Compose(Esse só para Max OS X) e virtualbox. Tudo que você precisa.

Mais informações sobre o ToolBox? Leia aqui.

toolboxDocker Engine 1.8

Essa nova versão da engine do Docker trás as novidades mais impactantes desse lançamento! Lembra que no lançamento que divulguei aqui, foi informado que o Docker tinha suporte a logs? Então, agora esse suporte aumentou, é suportado GELF e Fluentd.

Agora está estável a possibilidade de volumes de empresas terceiras! Tal como Blockbridge, Ceph, ClusterHQ, EMC e Portworx.

O binário docker agora tem suporte a enviar arquivos para o container:

docker cp foo.txt mycontainer:/foo.txt

O parâmetro “ps” agora tem suporte a modificação de formato “–format”.

E por fim, agora as configurações de cliente docker são armazenadas em ~/.docker. No caso de precisar executar múltiplas configurações em uma só máquina, você pode usar o parâmetro –config ou a variável de ambiente DOCKER_CONFIG.



Como adicionar virtualhost aos logs do Varnish

15 de Agosto de 2015, por PSL-BA Feeds - 0sem comentários ainda

Clone trooper segurando caneta

Há algum tempo atrás escrevi um post mostrando como configurar o Varnish para escrever logs num formato modificado do Combined Log Format do Apache, esta modificação foi feita para adicionar o virtualhost %v no início de cada registro do log e na sintaxe do Apache se parece com o seguinte:

LogFormat "%v %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined

Isto foi feito com o varnishncsa-vhost, um script que faz o Varnish armazenar logs seguindo o formato acima, este script deveria estar obsoleto já que versões recentes do Varnish suportam customizar o formato dos logs através da opção -F, mas um problema no pacote Debian impede de fazer isto do “jeito certo”™.

Este problema foi citado em Workaround for broken varnishncsa logging due to shell mishandling of spaces in LOG_FORMAT variables e algumas soluções foram sugeridas, mas todas elas tem um “ar” de armengue. O problema já foi relatado no Debian em #657449 varnishncsa: please add a config option to allow a custom logging format (patch) mas ainda não foi solucionado.

Porque estou contando esse “blá blá blá”?

Recentemente precisei alterar o formato dos logs do Varnish em um servidor de produção e acabei utilizando o varnishncsa-vhost novamente e ele funcionou muito bem, isto me salvou dos sedutores “armengues que quebram na próxima atualização”.

Então se isto for útil para você de alguma forma utilize o repositório abaixo, eu subi uma nova versão do pacote Debian do varnishncsa-vhost lá:

deb http://debian.joenio.me unstable/


c3video for debconf #5

14 de Agosto de 2015, por PSL-BA Feeds - 0sem comentários ainda

This is a follow-up to my previous post related the DebConf videoteam using a new software stack for the next conferences: http://acaia.ca/~tiago/posts/c3video-for-dc-take-4/.

This is about the encoding step from C3TT, mostly done by the script named D-encoding.

We can have many different encoding templates in the system. They're XSLT files which will generate the XML needed to create the local encoding commands. We can have more than one encoding template assigned for a conference.

/images/c3tt_encoding.png

XSLT encoding templates

A general comment: each meta ticket (say, the original ticket with meta info about the talk) will generate two children tickets over time, a recording one and a encoding one, with their own states. If things go wrong, a ingest ticket is created. More details can be checked here.

/images/c3tt_children_tickets.png

Children tickets

So I've got the proper encoded files in my Processing.Path.Output directory. The ticket is marked as encoded by the script. There's also a postencoding step, executed by E-postencoding. As I could understand, it's intended to be a general post-processing hook for encoded files. For instance, it can produces an audio file and make it available on Auphonic service. As we won't use that, we may want to set the property Processing.Auphonic.Enable to no.

The next step starts from the operator side. Just going to the Releasing tab in the web interface, choosing the ticket to check and doing a quick review in the encoded file:

/images/c3tt_releasing.png

Releasing tab

Then, if everything looks fine, click Everthing's fine:

/images/c3tt_check.png

Check encoded file

From this point the ticket will be marked as checked and the next script (F-postprocessing) will take care of pushing the video(s)/audio(s) to the target place, as defined by Publishing.UploadTarget. I had to set myself the encoding template property EncodingProfile.Extension. We can optionally set Publishing.UploadOptions. (keep that in mind, seems not documented elsewhere)

So I have now the first DebCamp encoded video file uploaded to an external host, entirely processed using the C3TT software stack. We may also want to use a very last script to release the videos (eg. as torrents, to different mirrors and other onlive services) if needed. This is script-G-release.pl, which unlike others, won't be run by the screen UI in the sequence. It has some parameters hardcoded on it, although code is very clear and ready to be hacked. It'll also mark the ticket as Released.

/images/c3tt_released.png

Released!

That's all for now! In summary: I've been able to install and set C3TT up during a few days in DebCamp, and will be playing with it during DebConf. In case things go well we'll probably be using this system as our video processing environment for the next events.

We can access most CCC VoC software from https://github.com/voc. By having a look at what they're developing I feel that we (DebConf and CCC) share quite the same technical needs. And most important, the same spirit of community work for bringing part of the conference to those unable to attend.

DebCamp was warm!



c3video for debconf #4

13 de Agosto de 2015, por PSL-BA Feeds - 0sem comentários ainda

This is a follow-up to my previous post related the DebConf videoteam using a new software stack for the next conferences: http://acaia.ca/~tiago/posts/c3video-for-dc-take-3/.

As mentioned before, C3TT provides a set of scripts which will work in background for most reviewing and video processing tasks. The first will just check if the talk is done and mark the related ticket as recorded.

The second script, B-mount4cut, does a nice job by mounting a custom fuse filesystem providing the following files (more detailed explanation here:

uncut.dv: full original dv file used as input file for the final trimming.

project.kdenlive: Kdenlive project file for the operator. Once it's saved with the trim marks, fuse-vdv will do a parse on it and use the marks for cutting.

cut.dv: contains only the frames between the trim marks extracted from project.kdenlive.

cut-complete.dv: contains the frames between the trim marks extracted from project.kdenlive, plus a prepended intro and an appended video. Paths for these files should be previously set in the web interface as properties Processing.Path.Outro and Processing.Path.Intros. The outro file can be, for instance, an appended video file with a common thanks for sponsors. The intro files is usually an individual frame for each talk, being a colorful presentation poster. We can also set the intro duration in the Processing.Duration.Intro property.

cut.wav: demuxed audio from cut.dv

Note: in fact, fuse-vdv provides virtual video files as a concatenation of original input files, so avoiding copying large and redundant data. Ideally, these fuse mountpoints will be shared over the network for operators via glusterFS, but I'll skip that for now.

After adding the trimming marks and saving the project using Kdenlive, the operator should go to the web interface and mark the ticket as cut:

/images/c3tt_cut.png

Mark ticket as cut

Note: I've been able to do the marks in Kdenlive using double-click in the video, then editing the crop start/end options. The buttons "[" and "]" didn't work in my Kdenlive version for some unknown reason.

In the current DebConf video environment I had to make a link builder for translating the path/file names to the C3TT format. So, for the Amsterdam/2015-08-13/09:57:02.dv we should have a amsterdam-2015.08.13-09_57_02.dv symlink.

From now the system will delivery the next tasks to C-cut-postprocessor script. This script will just check the marks from the Kdenlive project file and do the cutting job. So far it has worked perfectly here for the first video sessions in DebCamp, with zero hack in the original code, wow!

Next post will be about the encoding script, named D-encoding.



c3video for debconf #3

12 de Agosto de 2015, por PSL-BA Feeds - 0sem comentários ainda

This is a follow-up to my previous post related the DebConf videoteam using a new software stack for the next conferences: http://acaia.ca/~tiago/posts/c3video-for-dc-take-2/.

An outdated documentation for current subject is available at https://wiki.fem.tu-ilmenau.de/streaming/projekte/c3/28c3/crs/pipeline. Although the system may work differently nowadays, the basic idea remains the same. A newer, but incomplete documentation can be found in https://repository.fem.tu-ilmenau.de/trac/c3tt/wiki. Btw, CCC people from #voc at hackint.eu have been very kind and supportive.

I've set an instance of C3TT for DebConf15 in http://c3tt.acaia.ca/. If you want to play with it just ping me in #debconf-video at oftc. As you can see, we can keep a single external C3TT server for all Debian events, without much work left to the local side, doesn't it sound amazing?

Setting a new conference

Go to Projects, then Create.

In the project area we'll need to import the Tickets. Tickets will come from the schedule file, which is a XML as generated from frab. With a minor hack we've been able to make the schedule XML from DebConf Summit quite compatible to it (kudos cate!):

/images/import_tickets.png

Importing tickets

By importing the schedule from https://summit.debconf.org/debconf15.xml we'll be asked from which rooms we want to import the events. Usually those that have video coverage will be selected:

/images/chosing_rooms.png

Choosing rooms

Then, we may want to exclude some talks that we won't provide video:

/images/chosing_talks.png

Choosing talks

We're also required to adjust some Properties for a given conference. An example with some explanation of these properties is availabe at https://c3voc.de/wiki/c3tracker. For my initial tests the ones below seem to be enough:

/images/c3tt_properties.png

Setting properties

The backend: basic understand

The screen UI mentioned above will run a set of scripts in background which will automate most of the tasks, preparing videos for cutting to deploying them in different online services.

Tab 0: A-recording-scheduler

Each 30 seconds it will check if there's any ticket in the state scheduled or recording. It's based in the start/end datetime of the talk, so the ticket will be kept as scheduled (current < talk start), or marked as recording (start => current =< end) or recorded (current > end).

Tab 1: B-mount4cut

Each 30 seconds it will check if there's any ticket in the state recorded. That means the talk is already finished, and the raw video file is available in the path which has previously been set as a property (Path.Capture) in the web interface.

For each ticket marked as recorded it will try to find the related video file in the capture path. The file format should be <room>-YYYY-MM-DD_HH-MM-SS.<extension>. The script will then use fuse-vdv to create a custom filesystem with some needed files for human interaction (fancy stuff!).

Here's an example of talks in a room called Heidelberg, after being recorded and auto-mounted by the B-mount4cut script:

/images/c3tt_fuse.png

Mounting custom fuse FS

The human interaction is just a short review process using Kdenlive. The reviewers will access these files via a glusterFS network share. There's even a Debian Virtualbox image provided for that, including all the necessary tools. I'm going into this right now and will report what I get in the next hours.

Hopefully the following scripts will also be covered, very soon-ish :)

Tab 2: C-cut-postprocessor

Tab 3: D-encoding

Tab 4: E-postencoding (auphonic)

Tab 5: F-postprocessing(upload)

DebCamp is fun.