maio, 2012 | BSD INFO

Post em Destaque

BSD Magazine mês 03/2018

Saiu a edição do mês de março da revista que fala do mundo BSD e Software Livre. Nessa edição temos casadinha de jogos no OpenBSD, um rápido início com Kubernetes (k8s) e GKE (Google Kubernetes Engine), tunando um FreeBSD, gerenciar múltiplas instalações Perl 6 e outras. var hupso_services_t=new...

Leia mais...

Por que pessoas usam FreeBSD?

Posted by gondim | Posted in Dicas, FreeBSD | Posted on 31-05-2012

7

Eu recentemente perguntei para alguns usuários FreeBSD por que eles estão usando o sistema e essas foram as respostas que recebi:

A Comunidade:

FreeBSD é orientado pela Comunidade e mesmo tendo muitos usuários corporativos e contribuidores, eles não afetam a forma como o FreeBSD é conduzido pela Comunidade. FreeBSD tem listas de discussões ativas, fóruns e canais de IRC onde usuários experientes e desenvolvedores estão sempre dispostos a ajudar os menos experientes.

Abaixo a lista atual das listas de discussões. Acharam pouco?

Lista de discussão brasileira: http://www.fug.com.br

freebsd-advocacy FreeBSD Evangelism
freebsd-announce Important events and project milestones
freebsd-arch Architecture and design discussions
freebsd-bugbusters Discussions pertaining to the maintenance of the FreeBSD problem report database and related tools
freebsd-bugs Bug reports
freebsd-chat Non-technical items related to the FreeBSD community
freebsd-chromium FreeBSD-specific Chromium issues
freebsd-current Discussion concerning the use of FreeBSD-CURRENT
freebsd-isp Issues for Internet Service Providers using FreeBSD
freebsd-jobs FreeBSD employment and consulting opportunities
freebsd-questions User questions and technical support
freebsd-security-notifications Security notifications
freebsd-stable Discussion concerning the use of FreeBSD-STABLE
freebsd-test Where to send your test messages instead of one of the actual lists
freebsd-acpi ACPI and power management development
freebsd-afs Porting AFS to FreeBSD
freebsd-aic7xxx Developing drivers for the Adaptec® AIC 7xxx
freebsd-amd64 Porting FreeBSD to AMD64 systems
freebsd-apache Discussion about Apache related ports
freebsd-arm Porting FreeBSD to ARM® processors
freebsd-atm Using ATM networking with FreeBSD
freebsd-binup Design and development of the binary update system
freebsd-bluetooth Using Bluetooth® technology in FreeBSD
freebsd-cluster Using FreeBSD in a clustered environment
freebsd-cvsweb CVSweb maintenance
freebsd-database Discussing database use and development under FreeBSD
freebsd-desktop Using and improving FreeBSD on the desktop
freebsd-doc Creating FreeBSD related documents
freebsd-drivers Writing device drivers for FreeBSD
freebsd-eclipse FreeBSD users of Eclipse IDE, tools, rich client applications and ports.
freebsd-embedded Using FreeBSD in embedded applications
freebsd-eol Peer support of FreeBSD-related software that is no longer supported by the FreeBSD project.
freebsd-emulation Emulation of other systems such as Linux/MS-DOS®/Windows®
freebsd-firewire FreeBSD FireWire® (iLink, IEEE 1394) technical discussion
freebsd-fs File systems
freebsd-gecko Gecko Rendering Engine issues
freebsd-geom GEOM-specific discussions and implementations
freebsd-gnome Porting GNOME and GNOME applications
freebsd-hackers General technical discussion
freebsd-hardware General discussion of hardware for running FreeBSD
freebsd-i18n FreeBSD Internationalization
freebsd-ia32 FreeBSD on the IA-32 (Intel® x86) platform
freebsd-ia64 Porting FreeBSD to Intel’s upcoming IA64 systems
freebsd-ipfw Technical discussion concerning the redesign of the IP firewall code
freebsd-isdn ISDN developers
freebsd-jail Discussion about the jail(8) facility
freebsd-java Java™ developers and people porting JDK™s to FreeBSD
freebsd-kde Porting KDE and KDE applications
freebsd-lfs Porting LFS to FreeBSD
freebsd-mips Porting FreeBSD to MIPS®
freebsd-mobile Discussions about mobile computing
freebsd-mono Mono and C# applications on FreeBSD
freebsd-mozilla Porting Mozilla to FreeBSD
freebsd-multimedia Multimedia applications
freebsd-new-bus Technical discussions about bus architecture
freebsd-net Networking discussion and TCP/IP source code
freebsd-office Office applications on FreeBSD
freebsd-performance Performance tuning questions for high performance/load installations
freebsd-perl Maintenance of a number of Perl-related ports
freebsd-pf Discussion and questions about the packet filter firewall system
freebsd-platforms Concerning ports to non Intel architecture platforms
freebsd-ports Discussion of the Ports Collection
freebsd-ports-announce Important news and instructions about the Ports Collection
freebsd-ports-bugs Discussion of the ports bugs/PRs
freebsd-ppc Porting FreeBSD to the PowerPC®
freebsd-proliant Technical discussion of FreeBSD on HP ProLiant server platforms
freebsd-python FreeBSD-specific Python issues
freebsd-rc Discussion related to the rc.d system and its development
freebsd-realtime Development of realtime extensions to FreeBSD
freebsd-ruby FreeBSD-specific Ruby discussions
freebsd-scsi The SCSI subsystem
freebsd-security Security issues affecting FreeBSD
freebsd-small Using FreeBSD in embedded applications (obsolete; use freebsd-embedded instead)
freebsd-sparc64 Porting FreeBSD to SPARC® based systems
freebsd-standards FreeBSD’s conformance to the C99 and the POSIX® standards
freebsd-sysinstall sysinstall(8) development
freebsd-threads Threading in FreeBSD
freebsd-tilera Porting FreeBSD to the Tilera family of CPUs
freebsd-tokenring Support Token Ring in FreeBSD
freebsd-toolchain Maintenance of FreeBSD’s integrated toolchain
freebsd-usb Discussing FreeBSD support for USB
freebsd-virtualization Discussion of various virtualization techniques supported by FreeBSD
freebsd-vuxml Discussion on VuXML infrastructure
freebsd-x11 Maintenance and support of X11 on FreeBSD
freebsd-xen Discussion of the FreeBSD port to Xen™ — implementation and usage
freebsd-xfce XFCE for FreeBSD — porting and maintaining
freebsd-zope Zope for FreeBSD — porting and maintaining
freebsd-hubs People running mirror sites (infrastructural support)
freebsd-user-groups User group coordination
freebsd-vendors Vendors pre-release coordination
freebsd-wip-status FreeBSD Work-In-Progress Status
freebsd-wireless Discussions of 802.11 stack, tools, device driver development
freebsd-www Maintainers of www.FreeBSD.org
cvs-all /usr/(CVSROOT|doc|ports) All changes to any place in the tree (superset of other CVS commit lists)
cvs-doc /usr/(doc|www) All changes to the doc and www trees
cvs-ports /usr/ports All changes to the ports tree
cvs-projects /usr/projects All changes to the projects tree
cvs-src /usr/src All changes to the src tree (generated by the svn-to-cvs importer commits)
svn-src-all /usr/src All changes to the Subversion repository (except for user and projects)
svn-src-head /usr/src All changes to the “head” branch of the Subversion repository (the FreeBSD-CURRENT branch)
svn-src-projects /usr/projects All changes to the projects area of the src Subversion repository
svn-src-release /usr/src All changes to the releases area of the src Subversion repository
svn-src-releng /usr/src All changes to the releng branches of the src Subversion repository (the security / release engineering branches)
svn-src-stable /usr/src All changes to the all stable branches of the src Subversion repository
svn-src-stable-6 /usr/src All changes to the stable/6 branch of the src Subversion repository
svn-src-stable-7 /usr/src All changes to the stable/7 branch of the src Subversion repository
svn-src-stable-8 /usr/src All changes to the stable/8 branch of the src Subversion repository
svn-src-stable-9 /usr/src All changes to the stable/9 branch of the src Subversion repository
svn-src-stable-other /usr/src All changes to the older stable branches of the src Subversion repository
svn-src-svnadmin /usr/src All changes to the administrative scripts, hooks, and other configuration data of the src Subversion repository
svn-src-user /usr/src All changes to the experimental user area of the src Subversion repository
svn-src-vendor /usr/src All changes to the vendor work area of the src Subversion repository

Para saber mais sobre as listas acima e como assiná-las acesse aqui.

Estabilidade:

Estabilidade significa muitas coisas diferentes. FreeBSD muito raramente falha (e quando isso acontece, geralmente é devido à falhas de hardware), mas ao mesmo tempo que isso era vanglorioso umas décadas atrás, agora é uma característica esperada para qualquer sistema operacional.

Estabilidade no FreeBSD significa mais do que isso. Isso significa que atualizar o sistema não necessita de atualizar o usuário. Interfaces de configuração mudam ao longo do tempo, mas apenas quando há uma boa razão. Se você aprendeu a usar o FreeBSD em 2000, então a maioria de seu conhecimento ainda seria relevante.

Compatibilidade com versões anteriores é muito importante para a equipe do FreeBSD, e qualquer release de uma major release espera-se que seja capaz de executar qualquer código – incluindo os módulos do kernel – que funcionaram em uma versão anterior.

A estabilidade no FreeBSD é uma coisa realmente relevante e na maior parte dos problemas que já tive usando FreeBSD, foram causados por hardwares que apresentaram problemas. Temos que lembrar que para servidores existem hardwares adequados e que usar equipamentos para desktops não é nada bom para a estabilidade.

Configuração Simples:

O serviço de inicialização do FreeBSD é muito simples. Cada serviço, se for parte da base do sistema ou instalado de um port, vem com um script que é responsável por iniciar e parar este e freqüêntemente alguma outra opção. O arquivo /etc/rc.conf contém uma lista de variáveis para habilitar e configurar serviços. Quer habilitar ssh? Apenas adicione sshd_enable=”YES” para o seu arquivo rc.conf. Este sistema torna mais fácil de ver tudo que será iniciado no boot.

O sistema RCng que lê este arquivo, entende as dependências entre os serviços e então pode automaticamente rodar eles em paralelo ou esperar até que um finalize antes de iniciar as coisas que precise. Você obtem todos os benefícios de um sistema moderno de configuração, sem uma interface complexa.

Ports:

A árvore do ports contém uma enorme coleção de software de terceiros, incluindo as versões mais antigas de algumas coisas onde a userbase é dividida sobre os benefícios da atualização e um monte de programas de nicho. As probabilidades são, qualquer coisa que você queira executar, que funcione em FreeBSD, estará lá.

Ao contrário de alguns outros sistemas, FreeBSD mantém uma divisão clara entre o sistema base e o ports e pacotes de terceiros. Todos os softwares de terceiros vão em /usr/local, então se você quiser mudar o propósito de uma máquina basta simplesmente deletar todos os pacotes instalados e depois instalar os pacotes que deseja.

A próxima ferramenta pkg-ng tornará o trabalho com pacotes binários ainda mais fácil , embora instalação de fontes será ainda suportada para pessoas que quiserem um nível de configurabilidade.

Segurança:

Segurança é vital para qualquer máquina conectada em rede. FreeBSD fornece um número de ferramentas para assegurar que você possa manter um sistema seguro, tais como:

  • Jails, permitindo você executar aplicações – ou sistemas inteiros – em uma sandbox que não pode acessar o resto do sistema. Com ferramentas como ezjail e ZFS você pode instantaneamente criar uma nova jail com o clone de um sistema existente, usando uma pequena quantidade de espaço em disco, e executar dentro dela código não confiável.
  • Mandatory Access Control, do projeto TrustedBSD, permitindo você configurar políticas de controle de acesso para todos os recursos do sistema operacional.
  • Capsicum, à partir do FreeBSD 9, permite aos desenvolvedores facilmente implementarem separação de privilégios, reduzindo o impacto de código comprometido.
  • O sistema VuXML para publicar vulnerabilidades no ports, que integrado com ferramentas como portaudit,  de modo que seu e-mail diário de segurança lhe dirá sobre qualquer vulnerabilidade conhecida em softwares instalados do ports
  • Auditoria de eventos de Segurança, usando o padrão BSM.

E, claro, todas as características padrões que você esperaria de um sistema UNIX moderno, incluindo IPSec, SSH, e assim por diante.

ZFS:

Cheap snapshots, clones, end-to-end checksums, deduplication, compression, e sem a necessidade de decidir o tamanho das partições na instalação. O que não está gostando? Use o ZFS por poucos dias e volte para um doloroso gerenciador de volume mais tradicional. Se você quiser testar alguma coisa com ZFS então apenas crie um snapshot e faça um roll back se o que você fez não funcionar.

Se você está usando jails, então ZFS permitirá você clonar uma jail em menos de um segundo independente de quão grande seja a jail.

GEOM:

Mesmo sem o ZFS, FreeBSD vem com rico sistema de armazenamento. Camadas GEOM provedores e consumidores de forma arbitrária, permitindo você usar duas máquinas em rede para armazenamento de alta disponibilidade, use o nível de RAID da sua escolha ou adicione características como compressão ou encriptação.

Working Sound:

FreeBSD 4 introduziu no kernel o sound mixing, então multiplas aplicações podem tocar som ao mesmo tempo, mesmo quando usando placas de som baratas sem suporte à mixagem por hardware. FreeBSD 5 automaticamente alocou novos canais para aplicações, sem qualquer configuração.

Meu sistema, do jeito que eu quero:

FreeBSD dá à você um sistema UNIX-like fácil de usar e trabalhar. O sistema base pode facilmente ser extendido. Se você quiser rodar KDE ou GNOME, você precisa instalar o meta pacote da versão que você preferir. Se você quiser um servidor sem monitor, teclado e mouse, este é muito fácil de instalar as ferramentas que você deseja.

É fácil de instalar o FreeBSD via porta serial e configurar o sistema inteiro de um terminal. É fácil também instalar e usar qualquer ambiente desktop existente. As decisões sobre o tipo de sistema que você quer usar são deixadas pra você mesmo decidir.

O texto acima foi tirado daqui e adicionei algumas coisas.

Share Button

Novas vulnerabilidades no FreeBSD – OpenSSL e Crypt

Posted by gondim | Posted in FreeBSD, Segurança | Posted on 30-05-2012

Tags:,

1

As vulnerabilidades encontradas não aparecerão no portaudit e por isso deve ser dada uma atenção melhor. Muitos programas utilizam o openssl e o crypt. Se você compilou algum programa estaticamente com essas libs então precisará recompilá-los após aplicar os patches.
======================================================================
FreeBSD-SA-12:01.openssl                                    Security Advisory                               The FreeBSD Project

Topic:          OpenSSL multiple vulnerabilities

Category:       contrib
Module:         openssl
Announced:      2012-05-03
Credits:        Adam Langley, George Kadianakis, Ben Laurie, Ivan Nestlerode, Tavis Ormandy
Affects:        All supported versions of FreeBSD.
Corrected:      2012-05-30 12:01:28 UTC (RELENG_7, 7.4-STABLE)
2012-05-30 12:01:28 UTC (RELENG_7_4, 7.4-RELEASE-p8)
2012-05-30 12:01:28 UTC (RELENG_8, 8.3-STABLE)
2012-05-30 12:01:28 UTC (RELENG_8_3, 8.3-RELEASE-p2)
2012-05-30 12:01:28 UTC (RELENG_8_2, 8.2-RELEASE-p8)
2012-05-30 12:01:28 UTC (RELENG_8_1, 8.1-RELEASE-p10)
2012-05-30 12:01:28 UTC (RELENG_9, 9.0-STABLE)
2012-05-30 12:01:28 UTC (RELENG_9_0, 9.0-RELEASE-p2)
CVE Name:       CVE-2011-4576, CVE-2011-4619, CVE-2011-4109, CVE-2012-0884, CVE-2012-2110

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:http://security.FreeBSD.org/>.

0.   Revision History

v1.0  2012-05-02 Initial release.
v1.1  2012-05-30 Updated patch to add SGC and BUF_MEM_grow_clean(3) bug
fixes.

I.   Background

FreeBSD includes software from the OpenSSL Project.  The OpenSSL Project is
a collaborative effort to develop a robust, commercial-grade, full-featured
Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3)
and Transport Layer Security (TLS v1) protocols as well as a full-strength
general purpose cryptography library.

II.  Problem Description

OpenSSL fails to clear the bytes used as block cipher padding in SSL 3.0
records when operating as a client or a server that accept SSL 3.0
handshakes.  As a result, in each record, up to 15 bytes of uninitialized
memory may be sent, encrypted, to the SSL peer.  This could include
sensitive contents of previously freed memory. [CVE-2011-4576]

OpenSSL support for handshake restarts for server gated cryptography (SGC)
can be used in a denial-of-service attack. [CVE-2011-4619]

If an application uses OpenSSL’s certificate policy checking when
verifying X509 certificates, by enabling the X509_V_FLAG_POLICY_CHECK
flag, a policy check failure can lead to a double-free. [CVE-2011-4109]

A weakness in the OpenSSL PKCS #7 code can be exploited using
Bleichenbacher’s attack on PKCS #1 v1.5 RSA padding also known as the
million message attack (MMA). [CVE-2012-0884]

The asn1_d2i_read_bio() function, used by the d2i_*_bio and d2i_*_fp
functions, in OpenSSL contains multiple integer errors that can cause
memory corruption when parsing encoded ASN.1 data.  This error can occur
on systems that parse untrusted ASN.1 data, such as X.509 certificates
or RSA public keys. [CVE-2012-2110]

III. Impact

Sensitive contents of the previously freed memory can be exposed
when communicating with a SSL 3.0 peer.  However, FreeBSD OpenSSL
version does not support SSL_MODE_RELEASE_BUFFERS SSL mode and
therefore have a single write buffer per connection.  That write buffer
is partially filled with non-sensitive, handshake data at the beginning
of the connection and, thereafter, only records which are longer than
any previously sent record leak any non-encrypted data.  This, combined
with the small number of bytes leaked per record, serves to limit to
severity of this issue. [CVE-2011-4576]

Denial of service can be caused in the OpenSSL server application
supporting server gated cryptography by performing multiple handshake
restarts. [CVE-2011-4619]

The double-free, when an application performs X509 certificate policy
checking, can lead to denial of service in that application.
[CVE-2011-4109]

A weakness in the OpenSSL PKCS #7 code can lead to a successful
Bleichenbacher attack.  Only users of PKCS #7 decryption operations are
affected.  A successful attack needs on average 2

^20

messages. In
practice only automated systems will be affected as humans will not be
willing to process this many messages.  SSL/TLS applications are not
affected. [CVE-2012-0884]

The vulnerability in the asn1_d2i_read_bio() OpenSSL function can lead
to a potentially exploitable attack via buffer overflow.  The SSL/TLS
code in OpenSSL is not affected by this issue, nor are applications
using the memory based ASN.1 functions.  There are no applications in
FreeBSD base system affected by this issue, though some 3rd party
consumers of these functions might be vulnerable when processing
untrusted ASN.1 data.  [CVE-2012-2110]

The patch provided with the initial version of this advisory introduced
bug to the Server Gated Cryptography (SGC) handshake code, that could
cause SGC handshake to fail for a legitimate client.  The updated patch
also fixes the return error code in the BUF_MEM_grow_clean(3) function in the
buffer size check code introduced by the CVE-2012-2110 fix.

IV.  Workaround

No workaround is available.

V.   Solution

Perform one of the following:

1) Upgrade your vulnerable system to 7-STABLE, 8-STABLE or 9-STABLE,
or to the RELENG_7_4, RELENG_8_3, RELENG_8_2, RELENG_8_1, RELENG_9_0
security branch dated after the correction date.

2) To update your vulnerable system via a source code patch:

The following patches have been verified to apply to FreeBSD 7.4, 8.3,
8.2, 8.1, and 9.0 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

# fetch http://security.FreeBSD.org/patches/SA-12:01/openssl2.patch
# fetch http://security.FreeBSD.org/patches/SA-12:01/openssl2.patch.asc

NOTE: The patch distributed at the time of the original advisory fixed
the security vulnerability, but introduced a bug to the SGC handshake
code that can cause the SGC handshake to fail for a legitimate client.
Systems to which the original patch was applied should be patched with
the following corrective patch, which contains only the additional
changes required to fix the newly-introduced SGC handshake bug.  The
updated patch also corrects an error code for an error check introduced
in the original patch.

# fetch http://security.FreeBSD.org/patches/SA-12:01/openssl-sgc-fix.patch
# fetch http://security.FreeBSD.org/patches/SA-12:01/openssl-sgc-fix.patch.asc

b) Execute the following commands as root:

# cd /usr/src
# patch < /path/to/patch

c) Recompile the operating system as described in
<URL: http://www.freebsd.org/handbook/makeworld.html> and reboot the
system.

NOTE: Any third-party applications, including those installed from the
FreeBSD ports collection, which are statically linked to libcrypto(3)
should be recompiled in order to use the corrected code.

3) To update your vulnerable system via a binary patch:

Systems running 7.4-RELEASE, 8.3-RELEASE, 8.2-RELEASE, 8.1-RELEASE or
9.0-RELEASE on the i386 or amd64 platforms can be updated via the
freebsd-update(8) utility:

# freebsd-update fetch
# freebsd-update install

VI.  Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

CVS:

Branch                                                           Revision
Path
– ————————————————————————-
RELENG_7
src/crypto/openssl/crypto/buffer/buffer.c                   1.1.1.4.2.3
src/crypto/openssl/crypto/pkcs7/pk7_doit.c                 1.1.1.13.2.2
src/crypto/openssl/crypto/mem.c                             1.1.1.8.2.2
src/crypto/openssl/crypto/x509v3/pcy_map.c                  1.1.1.1.2.2
src/crypto/openssl/crypto/x509v3/pcy_tree.c                 1.1.1.2.2.2
src/crypto/openssl/crypto/asn1/a_d2i_fp.c                   1.1.1.3.2.1
src/crypto/openssl/ssl/ssl.h                               1.1.1.16.2.3
src/crypto/openssl/ssl/ssl_err.c                           1.1.1.11.2.3
src/crypto/openssl/ssl/s3_enc.c                            1.1.1.13.2.2
src/crypto/openssl/ssl/s3_srvr.c                           1.1.1.17.2.8
src/crypto/openssl/ssl/ssl3.h                               1.1.1.6.2.2
RELENG_7_4
src/UPDATING                                            1.507.2.36.2.10
src/sys/conf/newvers.sh                                  1.72.2.18.2.13
src/crypto/openssl/crypto/buffer/buffer.c               1.1.1.4.2.1.2.2
src/crypto/openssl/crypto/pkcs7/pk7_doit.c             1.1.1.13.2.1.2.1
src/crypto/openssl/crypto/mem.c                         1.1.1.8.2.1.2.1
src/crypto/openssl/crypto/x509v3/pcy_map.c              1.1.1.1.2.1.2.1
src/crypto/openssl/crypto/x509v3/pcy_tree.c             1.1.1.2.2.1.2.1
src/crypto/openssl/crypto/asn1/a_d2i_fp.c                  1.1.1.3.20.1
src/crypto/openssl/ssl/ssl.h                           1.1.1.16.2.2.2.1
src/crypto/openssl/ssl/ssl_err.c                       1.1.1.11.2.2.2.1
src/crypto/openssl/ssl/s3_enc.c                        1.1.1.13.2.1.2.1
src/crypto/openssl/ssl/s3_srvr.c                       1.1.1.17.2.5.2.2
src/crypto/openssl/ssl/ssl3.h                           1.1.1.6.2.1.2.1
RELENG_8
src/crypto/openssl/crypto/buffer/buffer.c                       1.2.2.2
src/crypto/openssl/crypto/pkcs7/pk7_doit.c                1.1.1.13.10.2
src/crypto/openssl/crypto/mem.c                                 1.2.2.1
src/crypto/openssl/crypto/x509v3/pcy_map.c                      1.2.2.1
src/crypto/openssl/crypto/x509v3/pcy_tree.c                     1.2.2.2
src/crypto/openssl/crypto/asn1/a_d2i_fp.c                  1.1.1.3.10.1
src/crypto/openssl/ssl/ssl.h                                    1.2.2.2
src/crypto/openssl/ssl/ssl_err.c                                1.2.2.2
src/crypto/openssl/ssl/s3_enc.c                                 1.2.2.2
src/crypto/openssl/ssl/s3_srvr.c                                1.3.2.6
src/crypto/openssl/ssl/ssl3.h                                   1.2.2.2
RELENG_8_3
src/UPDATING                                             1.632.2.26.2.4
src/sys/conf/newvers.sh                                   1.83.2.15.2.6
src/crypto/openssl/crypto/buffer/buffer.c                      1.2.14.2
src/crypto/openssl/crypto/pkcs7/pk7_doit.c            1.1.1.13.10.1.4.1
src/crypto/openssl/crypto/mem.c                                1.2.14.1
src/crypto/openssl/crypto/x509v3/pcy_map.c                     1.2.14.1
src/crypto/openssl/crypto/x509v3/pcy_tree.c                 1.2.2.1.6.1
src/crypto/openssl/crypto/asn1/a_d2i_fp.c                  1.1.1.3.26.1
src/crypto/openssl/ssl/ssl.h                                1.2.2.1.6.1
src/crypto/openssl/ssl/ssl_err.c                            1.2.2.1.6.1
src/crypto/openssl/ssl/s3_enc.c                             1.2.2.1.4.1
src/crypto/openssl/ssl/s3_srvr.c                            1.3.2.4.2.2
src/crypto/openssl/ssl/ssl3.h                               1.2.2.1.6.1
RELENG_8_2
src/UPDATING                                            1.632.2.19.2.10
src/sys/conf/newvers.sh                                  1.83.2.12.2.13
src/crypto/openssl/crypto/buffer/buffer.c                       1.2.8.2
src/crypto/openssl/crypto/pkcs7/pk7_doit.c            1.1.1.13.10.1.2.1
src/crypto/openssl/crypto/mem.c                                 1.2.8.1
src/crypto/openssl/crypto/x509v3/pcy_map.c                      1.2.8.1
src/crypto/openssl/crypto/x509v3/pcy_tree.c                 1.2.2.1.4.1
src/crypto/openssl/crypto/asn1/a_d2i_fp.c                  1.1.1.3.18.1
src/crypto/openssl/ssl/ssl.h                                1.2.2.1.4.1
src/crypto/openssl/ssl/ssl_err.c                            1.2.2.1.4.1
src/crypto/openssl/ssl/s3_enc.c                             1.2.2.1.2.1
src/crypto/openssl/ssl/s3_srvr.c                            1.3.2.3.2.2
src/crypto/openssl/ssl/ssl3.h                               1.2.2.1.4.1
RELENG_8_1
src/UPDATING                                            1.632.2.14.2.13
src/sys/conf/newvers.sh                                  1.83.2.10.2.14
src/crypto/openssl/crypto/buffer/buffer.c                       1.2.6.2
src/crypto/openssl/crypto/pkcs7/pk7_doit.c                1.1.1.13.16.1
src/crypto/openssl/crypto/mem.c                                 1.2.6.1
src/crypto/openssl/crypto/x509v3/pcy_map.c                      1.2.6.1
src/crypto/openssl/crypto/x509v3/pcy_tree.c                 1.2.2.1.2.1
src/crypto/openssl/crypto/asn1/a_d2i_fp.c                  1.1.1.3.16.1
src/crypto/openssl/ssl/ssl.h                                1.2.2.1.2.1
src/crypto/openssl/ssl/ssl_err.c                            1.2.2.1.2.1
src/crypto/openssl/ssl/s3_enc.c                                 1.2.6.1
src/crypto/openssl/ssl/s3_srvr.c                            1.3.2.2.2.2
src/crypto/openssl/ssl/ssl3.h                               1.2.2.1.2.1
RELENG_9
src/crypto/openssl/crypto/buffer/buffer.c                      1.2.10.2
src/crypto/openssl/crypto/pkcs7/pk7_doit.c                      1.2.2.1
src/crypto/openssl/crypto/mem.c                                1.2.10.1
src/crypto/openssl/crypto/x509v3/pcy_map.c                     1.2.10.1
src/crypto/openssl/crypto/x509v3/pcy_tree.c                     1.3.2.1
src/crypto/openssl/crypto/asn1/a_d2i_fp.c                  1.1.1.3.22.1
src/crypto/openssl/ssl/ssl.h                                    1.3.2.1
src/crypto/openssl/ssl/ssl_err.c                                1.3.2.1
src/crypto/openssl/ssl/s3_enc.c                                 1.3.2.1
src/crypto/openssl/ssl/s3_srvr.c                                1.7.2.2
src/crypto/openssl/ssl/ssl3.h                                   1.3.2.1
RELENG_9_0
src/UPDATING                                              1.702.2.4.2.4
src/sys/conf/newvers.sh                                    1.95.2.4.2.6
src/crypto/openssl/crypto/buffer/buffer.c                      1.2.12.2
src/crypto/openssl/crypto/pkcs7/pk7_doit.c                      1.2.4.1
src/crypto/openssl/crypto/mem.c                                1.2.12.1
src/crypto/openssl/crypto/x509v3/pcy_map.c                     1.2.12.1
src/crypto/openssl/crypto/x509v3/pcy_tree.c                     1.3.4.1
src/crypto/openssl/crypto/asn1/a_d2i_fp.c                  1.1.1.3.24.1
src/crypto/openssl/ssl/ssl.h                                    1.3.4.1
src/crypto/openssl/ssl/ssl_err.c                                1.3.4.1
src/crypto/openssl/ssl/s3_enc.c                                 1.3.4.1
src/crypto/openssl/ssl/s3_srvr.c                                1.7.4.2
src/crypto/openssl/ssl/ssl3.h                                   1.3.4.1
– ————————————————————————-

Subversion:

Branch/path                                                      Revision
– ————————————————————————-
stable/7/                                                         r236304
releng/7.4/                                                       r236304
stable/8/                                                         r236304
releng/8.3/                                                       r236304
releng/8.2/                                                       r236304
releng/8.1/                                                       r236304
stable/9/                                                         r236304
releng/9.0/                                                       r236304
– ————————————————————————-

VII. References

http://www.openssl.org/news/secadv_20120419.txt
http://www.openssl.org/news/secadv_20120312.txt
http://www.openssl.org/news/secadv_20120104.txt
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4576
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4619
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4109
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0884
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2110
http://lists.openwall.net/full-disclosure/2012/04/19/4

The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-12:01.openssl.asc

======================================================================
FreeBSD-SA-12:02.crypt                                      Security Advisory                                The FreeBSD Project

Topic:          Incorrect crypt() hashing

Category:       core
Module:         libcrypt
Announced:      2012-05-30
Credits:        Rubin Xu, Joseph Bonneau, Donting Yu
Affects:        All supported versions of FreeBSD.
Corrected:      2012-05-30 12:01:28 UTC (RELENG_7, 7.4-STABLE)
2012-05-30 12:01:28 UTC (RELENG_7_4, 7.4-RELEASE-p8)
2012-05-30 12:01:28 UTC (RELENG_8, 8.3-STABLE)
2012-05-30 12:01:28 UTC (RELENG_8_3, 8.3-RELEASE-p2)
2012-05-30 12:01:28 UTC (RELENG_8_2, 8.2-RELEASE-p8)
2012-05-30 12:01:28 UTC (RELENG_8_1, 8.1-RELEASE-p10)
2012-05-30 12:01:28 UTC (RELENG_9, 9.0-STABLE)
2012-05-30 12:01:28 UTC (RELENG_9_0, 9.0-RELEASE-p2)
CVE Name:       CVE-2012-2143

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:http://security.FreeBSD.org/>.

I.   Background

The crypt(3) function performs password hashing with additional code added
to deter key search attempts.

II.  Problem Description

There is a programming error in the DES implementation used in crypt()
when handling input which contains characters that can not be represented
with 7-bit ASCII.

III. Impact

When the input contains characters with only the most significant bit set
(0x80), that character and all characters after it will be ignored.

IV.  Workaround

No workaround is available, but systems not using crypt(), or which only
use it to handle 7-bit ASCII are not vulnerable.  Note that, because
DES does not have the computational complexity to defeat brute force
search on modern computers, it is not recommended for new applications.

V.   Solution

Perform one of the following:

1) Upgrade your vulnerable system to 7-STABLE, 8-STABLE, or 9-STABLE,
or to the RELENG_7_4, RELENG_8_3, RELENG_8_2, RELENG_8_1, or RELENG_9_0
security branch dated after the correction date.

2) To update your vulnerable system via a source code patch:

The following patches have been verified to apply to FreeBSD 7.4,
8.3, 8.2, 8.1 and 9.0 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

# fetch http://security.FreeBSD.org/patches/SA-12:02/crypt.patch
# fetch http://security.FreeBSD.org/patches/SA-12:02/crypt.patch.asc

# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/lib/libcrypt
# make obj && make depend && make && make install

NOTE: On the amd64 platform, the above procedure will not update the
lib32 (i386 compatibility) libraries.  On amd64 systems where the i386
compatibility libraries are used, the operating system should instead
be recompiled as described in
<URL:http://www.FreeBSD.org/handbook/makeworld.html>

3) To update your vulnerable system via a binary patch:

Systems running 7.4-RELEASE, 8.3-RELEASE, 8.2-RELEASE, 8.1-RELEASE,
or 9.0-RELEASE on the i386 or amd64 platforms can be updated via the
freebsd-update(8) utility:

# freebsd-update fetch
# freebsd-update install

VI.  Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

CVS:

Branch                                                           Revision
Path
– ————————————————————————-
RELENG_7
src/secure/lib/libcrypt/crypt-des.c                           1.16.24.1
RELENG_7_4
src/UPDATING                                            1.507.2.36.2.10
src/sys/conf/newvers.sh                                  1.72.2.18.2.13
src/secure/lib/libcrypt/crypt-des.c                           1.16.40.2
RELENG_8
src/secure/lib/libcrypt/crypt-des.c                           1.16.36.2
RELENG_8_3
src/UPDATING                                             1.632.2.26.2.4
src/sys/conf/newvers.sh                                   1.83.2.15.2.6
src/secure/lib/libcrypt/crypt-des.c                       1.16.36.1.8.2
RELENG_8_2
src/UPDATING                                            1.632.2.19.2.10
src/sys/conf/newvers.sh                                  1.83.2.12.2.13
src/secure/lib/libcrypt/crypt-des.c                       1.16.36.1.6.2
RELENG_8_1
src/UPDATING                                            1.632.2.14.2.13
src/sys/conf/newvers.sh                                  1.83.2.10.2.14
src/secure/lib/libcrypt/crypt-des.c                       1.16.36.1.4.2
RELENG_9
src/secure/lib/libcrypt/crypt-des.c                           1.16.42.2
RELENG_9_0
src/UPDATING                                              1.702.2.4.2.4
src/sys/conf/newvers.sh                                    1.95.2.4.2.6
src/secure/lib/libcrypt/crypt-des.c                       1.16.42.1.2.2
– ————————————————————————-

Subversion:

Branch/path                                                      Revision
– ————————————————————————-
stable/7/                                                         r236304
releng/7.4/                                                       r236304
stable/8/                                                         r236304
releng/8.3/                                                       r236304
releng/8.2/                                                       r236304
releng/8.1/                                                       r236304
stable/9/                                                         r236304
releng/9.0/                                                       r236304
– ————————————————————————-

VII. References

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2143

The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-12:02.crypt.asc

Share Button

Liberdade ou prisão?

Posted by gondim | Posted in FreeBSD, Software Livre, Tecnologia | Posted on 30-05-2012

Tags:, ,

5

Hoje acordei e resolvi abordar algo que realmente sempre me irritou. Algumas pessoas que pregam a liberdade muitas das vezes distorcem o que é liberdade em prol do fanatismo que criaram em suas cabeças. Chega ao ponto de tentar obrigar algo à ser livre de determinada maneira. Porque se não for assim não será livre o suficiente.

Isso muito me lembra fatos religiosos, que não vou citar nomes mas, que vemos por aí o tempo todo onde a religião de fulano é a melhor porque é a certa e a do sicrano é a errada. Assim como na religião qualquer coisa que impomos estamos retirando a liberdade daquela pessoa de escolher. Mostrar e ajudar no caminho à seguir é uma forma de ajudar mas sem impor nada. No nosso mundo do software livre é a mesma coisa. Vejo muitas pessoas brigando entre si e afirmando que suas distribuições GNU/Linux são melhores, mais simples, mais tradicionais. Sempre as mesmas desculpas para as desavenças e para que tudo isso? Cada um gosta e usa o que quer. Qual o problema de uma pessoa gostar de usar um Microsoft Windows? Se ele tem dinheiro e quer pagar pela licença de uso então é a escolha dele, a liberdade que ele tem de decidir e nós como seres humanos deveríamos entender isso e respeitar.

O fato de ser pago e fechado não torna um programa ruim ou cheio de bugs. Todos os sistemas tem o seu valor e a sua aplicação. A Apple está aí para provar o quanto um sistema fechado e proprietário pode agradar à tanta gente no mundo. Ah! Mas o sistema da Apple é baseado em FreeBSD. Sim é sim mas muita coisa foram eles que desenvolveram e fecharam. Eu acho justo sim é existir opções livres para que as pessoas sem recursos possam usar e ter acesso à mesma tecnologia.

Liberdade na Informação deveria ser um direito de todos, da humanidade.

Eu citei distribuições GNU/Linux como exemplo mas são só um exemplo de muitos. Se formos mais à fundo e analisarmos o caso da licença GPL v3 na qual os novos compiladores GCC à partir da versão > 4.2, estão incorporando. Qualquer programa compilado com o GCC licenciado na GPL v3 está sujeito às regras impostas por esta licença e isso não está agradando muita gente, inclusive ao Linus Torvalds. Devido à isso, muitos projetos estão ajudando e migrando para o uso do Clang/LLVM (licença BSD) com o intuito de abandonar o GCC.

Imagine que se você compilar um programa usando um compilador GCC com licença GPL v3 seu programa automaticamente passa à adotar a GPL v3 como sua licença e fica obrigado à seguir suas regras. Bem, como muitos dizem isso foi um tiro no pé para o Richard Stallman. Agora o Clang/LLVM passa à ser o grande objetivo e todo esforço está sendo colocado para que no FreeBSD 10.0 tanto o sistema quanto os ports possam ser 100% compiláveis com o Clang. Atualmente, para a comunidade FreeBSD, qualquer programa que não possa ser compilado com o Clang possui um bug e precisa ser corrigido o quanto antes.

Na minha visão a GPL v3 vai de contra qualquer coisa que se diga livre e a jogada do Stallman era a de querer obrigar à todos que aceitassem a GPL v3 mudando a licença de um dos maiores compiladores livres que tínhamos.

Tudo isso é notícia velha e já acontece faz um bom tempo mas é sempre bom relembrar.

“O homem livre é um lutador e a liberdade é algo que se conquista”
Nietzche

Share Button

Melhorando a segurança no FreeBSD – Parte 3

Posted by gondim | Posted in Dicas, FreeBSD, Segurança, Shell Script | Posted on 25-05-2012

Tags:, ,

2

Hoje venho falar de um complemento à segurança que é a visualização diária dos logs. Todo sysadmin deve olhar os logs diariamente para verificar possíveis problemas, tentativas de acessos não autorizados, ataques aos seus serviços, problemas com o hardware e por aí vai. Os logs estão aí para nos ajudar e embora seja um serviço trabalhoso, cansativo e chato, são os logs que nos salvam muitas das vezes.

O FreeBSD vem com uma ferramenta chamada Periodic que é um conjunto de shell scripts prontos e rodado pelo cron. Esses scripts são localizados em /etc/periodic, separados por:

daily
weekly
monthly
security

Os scripts nesses diretórios rodam diariamente, semanalmente e mensalmente. Os scripts em security também rodam diariamente mas são relacionados com segurança.

Se você gosta de aprender coisas novas e entende de shell script, dê uma olhada nesses scripts pois são muito interessantes e usam os comandos do sistema para isso. É uma forma de aprender mais sobre o sistema.

Nesse post, vamos instalar o portaudit, uma ferramenta que usamos para checar se temos alguma vulnerabilidade em pacotes que foram instalados do ports. Instalaremos o pacote ssmtp para envio dos logs por e-mail, para os servidores que vamos querer monitorar mas sem a necessidade de se ter um servidor de correio local. Por último faremos uma configuração no Periodic para que ele nos envie esses relatórios de segurança, diários, semanais e mensais.

Vamos começar com o portaudit que após instalado já adiciona um script dele para o periodic. O portaudit é usado para baixar uma listagem de vulnerabilidades do VuXML e checar se você tem alguma vulnerabilidade relacionada. Em caso positivo uma mensagem será mostrada apontando a vulnerabilidade ou vulnerabilidades que você tenha.

# cd /usr/ports/ports-mgmt/portaudit
# make install clean
# rehash       <- se tiver usando csh

O portaudit, como eu disse anteriormente, já instala um script no periodic conforme abaixo:

# pkg_info -L portaudit-0.6.0
Information for portaudit-0.6.0:

Files:
/usr/local/man/man1/portaudit.1.gz
/usr/local/sbin/portaudit
/usr/local/etc/portaudit.pubkey
/usr/local/etc/portaudit.conf.sample
/usr/local/etc/periodic/security/410.portaudit

Quando quiser checar manualmente por vulnerabilidades basta executar: portaudit -Fda

Nesse momento vamos instalar o ssmtp. Esse programa é útil quando a máquina monitorada não é um servidor de e-mail e você não quer instalar um SMTP  Server só para enviar os relatórios do periodic. Se a máquina estiver rodando um Servidor de Correio, não instale o ssmtp pois ele irá desconfigurar o seu servidor. Nesse caso pule a configuração abaixo e vá direto para a configuração do periodic.

# cd /usr/ports/mail/ssmtp
# make install clean
# make replace
# rehash     <- se tiver usando csh

Continuando a configuração do ssmtp, vamos precisar alterar 2 arquivos apenas que ficam em /usr/local/etc/ssmtp. Vamos supor que eu queira usar uma conta de e-mail qualquer, em algum servidor, para enviar os relatórios. Vamos aos dados fictícios abaixo:

  • servidor de e-mail: smtp.teste.com.br – porta 587/tcp para envio de e-mail autenticado conforme recomendação do Comitê Gestor.
  • conta de e-mail: [email protected]
  • senha da conta de e-mail: zUngA2378

Iremos usar esses dados acima para o envio de qualquer e-mail desse servidor que estamos configurando. Agora faremos o seguinte:

# cd /usr/local/etc/ssmtp
# touch revaliases
# touch ssmtp.conf
# chmod 640 revaliases ssmtp.conf
# chown root:ssmtp revaliases ssmtp.conf

Dentro do arquivo ssmtp.conf colocaremos a seguinte configuração do nosso exemplo:

root=postmaster
mailhub=smtp.teste.com.br:587
rewriteDomain=teste.com.br
hostname=_HOSTNAME_
UseSTARTTLS
[email protected]
AuthPass=zUngA2378

Dentro do arquivo revaliases colocaremos a configuração abaixo:

root:[email protected]:smtp.teste.com.br:587

Lembrando que esses dados citados são fictícios e você deve substituí-los pelos seus dados reais.

Feito essas configurações você pode testar enviando um e-mail para você dessa forma:

# mailx -s teste [email protected] <<EOF
Teste de envio de e-mail.
EOF

Bem, se você fez o teste acima sem trocar o e-mail: [email protected] pelo seu e-mail, então pare por aqui e estude mais.  🙂

Se tudo der certo você receberá um e-mail vindo do e-mail configurado no ssmtp e provando que está tudo funcionando como deveria.

Vamos agora finalizar a nossa configuração do periodic. Criaremos o arquivo /etc/periodic.conf e dentro deste colocaremos essas 5 linhas abaixo:

#!/bin/sh
daily_output=”[email protected]
weekly_output=”[email protected]
monthly_output=”[email protected]
daily_status_security_output=”[email protected]

Nas linhas acima estaremos enviando os relatórios diários, semanais, mensais e de segurança para o e-mail: [email protected].

Você pode consultar o arquivo /etc/defaults/periodic.conf para servir de referência e não deve alterar esse arquivo. Se quiser usar alguma variável de lá, copie ela e use no /etc/periodic.conf.

Bem, feito isso aguarde os relatórios que eles chegarão conforme configurado no /etc/crontab.

# Perform daily/weekly/monthly maintenance.
1       3       *       *       *       root    periodic daily
15      4       *       *       6       root    periodic weekly
30      5       1       *       *       root    periodic monthly

É isso e vejo vocês em breve.

Share Button

PBI: Entendendo como funciona o formato de pacotes do PC-BSD.

Posted by lgvalentim | Posted in Dicas, FreeBSD | Posted on 24-05-2012

Tags:, ,

1

O fato do PC-BSD ter uma instalacão fácil, intuitiva e agradável é sim um fato importante para sua popularizacão. Ser um sistema estável, de alta performance e seguro claramente não é suficiente para sua popularizacão em ambiente Desktop. Já, ser de fácil uso e ter um resultado rasoável por padrão após a instalacão, também é muito relevante para o perfil de usuários que o PC-BSD se destina: o usuário doméstico típico.

Porém, um dos principais fatores de destaque do PC-BSD no que tange a facilidade de uso é o seu sistema de instalacão de aplicacões de terceiros, o PBI: Push Button Installer, ou Instalador ao Apertar do Botão. O PBI é um formato especial e exclusivo do PC-BSD. Apesar de podermos usar pacotes pré-compilados (pkg_add) ou compilar a aplicacão localmente com a Colecão de Ports do FreeBSD, o formato padrão não é nenhum dos dois, e sim o PBI, que analisaremos agora em mais detalhes.

O Formato PBI – Visão Superficial

O formato de pacotes do instalador PBI é simples, parte do princípio que um PBI vai sempre instalar a aplicacão, todas as bibliotecas e dependências dessa aplicacão, em um compartimento único e isolado. Dessa forma não há conflitos de bibliotecas, não há também conflitos entre versões de dependências, nem há dependência da própria ABI nativa do sistema operacional.

A idéia por trás do conceito que o PBI trás é de um instalador que vai instalar aplicacões que vão rodar em qualquer versão do PC-BSD, e principalmente, que vai continuar plenamente funcional mesmo após atualizacões mesmo as mais radicais, com troca plena de ABI, com tanto que uma compatibilidade mínima seja mantida entre o sistema novo e suas versões anteriores – em kernel, os COMPAT_FREEBSD4, COMPAT_FREEBSD5, COMPAT_FREEBSD6, COMPAT_FREEBSDX;

Para isso, os arquivos com extensão .pbi são interpretados pelo PC-BSD como instalacão e são considerados executáveis. Esses executáveis são divididos essencialmente em quatro partes:

A primeira é a biblioteca de carregamento (o loader) que permite que o .pbi seja interpretado como um executável ELF. Ou seja são os Elf Loader Headers. A segunda parte contém embarcado o ícone da aplicacão que será instalada. A terceira camada tem as directivas e dados de configuracão do .pbi que identificam o que, onde e como será instalado. E finalmente a quarta etapa, são todos os dados da aplicacão, biblitecas e dependências, bem como os scripts que serão instalados.

O produto final de um arquivo .pbi é um executável auto-instalável:

[email protected]% file JavaJRE1.6.0-PV0.pbi
JavaJRE1.6.0-PV0.pbi: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.0 (700109), dynamically linked (uses shared libs), FreeBSD-style, not stripped

[email protected]% brandelf ./JavaJRE1.6.0-PV0.pbi
File ‘./JavaJRE1.6.0-PV0.pbi’ is of brand ‘FreeBSD’ (9).

Que de fato, é linkado dinamicamente apenas a própria ABI nativa (libc):

[email protected]% ldd ./JavaJRE1.6.0-PV0.pbi
./JavaJRE1.6.0-PV0.pbi:
libc.so.7 => /lib/libc.so.7 (0x2807e000)

E cujo prefix de instalacão é fora do padrão FreeBSD, quebra a hier(7) e também a especificacão POSIX, e fica isolado em /Programs, não tocando qualquer outro arquivo em infra-estrutura fora dessa hierarquia.

 

Entendendo o funcionamento de um Produto Instalado a partir de um PBI

Aqui chega a parte onde a abordagem por trás de um produto resultante de um PBI instalado deve ser avaliado e entendido. Os binários e bibliotecas criados de um PBI são exatamente iguais os criados da compilacão genérica de um Ports ou a instalacão de um package binários. O produto é o mesmo, mas sua estrutura instalada e a forma como são carregados, é a diferencão.

O coracão por trás do PBI é uma idéia simples, completamente funcional, mas com alguns efeitos colaterais. Todo binário já acompanha suas dependências e suas bibliotecas, e esses são isolados, e utilizados exclusivamente para aquela aplicacão.

A estrutura da instalacão de um PBI se baseia que tudo será instalado no /Programs (que por sua vez é um link simbólico para o /usr/Programs); e abaixo dele temos algumas estruturas, nem sempre todas utilizadas. A saber:

Programs/
Programs/bin/
Programs/lib/
Programs/etc/
Programs/rc.d/
Programs/rc.conf
Programs/<aplicacão>/

Todas aplicacões são instaladas em /Programs/<aplicacão>/, que é sempre constituído da seguinte organizacão hierárquica:

Programs/<aplicacão>/bin/
Programs/<aplicacão>/.sbin/
Programs/<aplicacão>/autolibs/
Programs/<aplicacão>/share/
Programs/<aplicacão>/libs (lincado para ./autolibs local)

Além disso temos sempre scripts executáveis:

Programs/<aplicacão>/PBI.FirstRun.sh
Programs/<aplicacão>/PBI.RemoveScript.sh
Programs/<aplicacão>/PBI.RemoveScript2.sh
Programs/<aplicacão>/PBI.SetupScript.sh
Programs/<aplicacão>/PBI.UpdateURL.sh

Os executáveis acima são rotinas executadas na primeira inicializacão da aplicacão depois de instalada, um script auxiliar que permite ao sistema de atualizacão de PBI avaliar se há atualizacões do PBI em questão, e por último os outros são rotinas de deinstalacão da aplicacão.

O mais importante é o:

Programs/<aplicacão>/autolibs/

 

Isso porque nessa estrutura estão todas, todas a bibliotecas de que o binário depende, bem como suas dependências, sejam essas bibliotecas ou aplicacões. Ou seja quando a aplicacão é executava, o contexto de bibliotecas dinâmicas do linker do loader (carregador) é isolado, e as bibliotecas disponíveis para aquele contexto de execussão é exclusivamente as que estivirem em Programs/<aplicacão>/autolibs/.

Inteligente não? Dessa forma não importa a ABI do sistema operacional, nem importa que bibliotecas existam ou não, que dependências existam ou não no restante do sistema, pois tudo que a aplicacão precisa, ela já “traz consigo”. Quase como se fosse um binário compilado estáticamente. Porém, não é estático, é dinâmico, e apesar de em disco haver redundância de bibliotecas, em memória os objetos iguais são sempre alocados em memória shadow, não havendo o mesmo consumo de memória que haveria se fossem todas aplicacões estáticamente compiladas.

O binário de inicializacão real (o verdadeiro produto da instalacão) fica disponível em:

Programs/<aplicacão>/bin/

Porém, o ambiente de execussão desse binário acontece através do que fica disponívem em:

Programs/bin/<aplicacão>

Que por sua vez é um link simbólico, que se referencia a um shell script disponível em:

Programs/<aplicacão>/.sbin/

E ai sim, esse shell script é onde fica a sacada, o pulo do gato do isolamento de contexto de bibliotecas. Vejamos um exemplo prático, o amsn instalado, instala um arquivo .desktop no Desktop, que é o link para a aplicacão, vejamos:

[Desktop Entry]
Name=aMSN
Exec=/Programs/aMSN0.97.2_1/.sbin/amsn
Type=Application
Path=/Programs/aMSN0.97.2_1/
Icon=/Programs/aMSN0.97.2_1/amsn.png

Ou seja ao clicar nesse ícone, é executado o  /Programs/aMSN0.97.2_1/.sbin/amsn, que por sua vez é um link simbólico para um shell script:

% ls -l /Programs/bin/amsn
lrwxr-xr-x  1 root  wheel  33 10 Dez 21:11 /Programs/bin/amsn -> /Programs/aMSN0.97.2_1/.sbin/amsn

 

 

O Executável de Inicializacão da Aplicacão

O shell script que faz o isolamento do contexto das bibliotecas dinâmicas e carrega a aplicacão pode ter algumas variacões, mas a essência geral é a seguinte:

A variável de ambiente LD_LIBRARY_PATH é populada, e seu único conteúdo é o Programs/<aplicacão>/autolibs/ ; com essa variável definida assim, o binário é executado em Programs/<aplicacão>/bin/<aplicacão>. Dessa forma qualquer biblioteca ou dependência que o binário precisa, só tem o Programs/<aplicacão>/autolibs/ onde carregar. Esse é o coracão por trás do ambiente instalado por um PBI.

Outros arquivos podem ser necessários, caso em que outras variáveis são populadas permitindo acesso as demais estruturas. Mas normalmente são apenas arquivos de referência de configuracão e comportamento, como share, ícones, configuracões padrão, diretivas de controle, etc.

Seguindo o estudo vamos analisar o que temos para iniciar o amsn:

#!/bin/sh
# Auto-Generated by PC-BSD
PATH=”/Programs/aMSN0.97.2_1/bin:$PATH”; export PATH
LANG=”`grep ^Language= ~/.kde/share/config/kdeglobals | cut -d “=” -f2`”; export LANG
LD_LIBRARY_PATH=”/Programs/aMSN0.97.2_1/autolibs/” ; export LD_LIBRARY_PATH
STDLOG=”${HOME}/.$$stdout”
STELOG=”${HOME}/.$$stderr”
(((( /Programs/aMSN0.97.2_1/bin/amsn  “[email protected]” || /PCBSD/bin/CrashHandler “bin/amsn” “${STDLOG}” “${STELOG}” ) | tee $STDLOG) 3>&1 1>&2 2>&3 | tee $STELOG) 3>&1 1>&2 2>&3)

rm $STDLOG >/dev/null 2>/dev/null
rm $STELOG >/dev/null 2>/dev/null

É esse o esqueleto padrão. Podem haver variacões, e de fato a infra-estrutura do PBI permite que hajam, para satisfazer os todos possíveis perfis de necessidade de aplicacões. Mas as variacões são apenas uma repeticão da idéia geral acima.

Avaliacão da Abordagem PBI

As impressões sobre a abordagem acima são as mais variadas. Sobre o PBI, já tivemos opinião de desenvolvedores Red Hat que mantém o padrão RPM, já tivemos opiniões de empacotadores Debian acostumados com os formatos de pacotes do Debian e toda a (bem criteriosa e inteligente, diga-se de passagem) estrutura de pacotes do Debian, e a opinião de Port Managers do Projeto FreeBSD, bem como mantenedores do PkgSrc.

De forma geral todos acham a idéia inteligente, porém, inadequada. O motivo é claro, ninguém gosta de ver tamanha redundância de bibliotecas e dependências como os PBI instalam. Porém, todos concordam, que poucas abordagens tem resultado tão prático e funcional. E acima de tudo, essa é a única abordagem livre de conflitos e problemas de dependências.

Efeitos Colaterais

Pro usuário final, porém, as consequências negativas da abordagem do PBI são duas: os PBI de forma geral são maiores do que poderiam ser, o download tem que trazer junto todas as dependências e bibliotecas que, de certa forma, podem já estar presentes no autolibs/ de alguma outra aplicacão ou na própria base do sistema operacional.

A segunda consequência é o espaco em disco. A abordagem dos PBI ocupa muito mais espaco em disco exatamente devido a essa redundância de bibliotecas e dependências. Em minhas análises, um conjunto simples de aplicacões, Firefox, aMSN, OpenOffice e Java, o consumo de espaco em disco é 34% superior com PBI do que instalado por pacote (package) pré-compilado. Se comparado com aplicacões compiladas localmente e com grande nível de customizacão de Build Time a diferenca pode ser ainda maior.

Resultados Obtidos pela Abordagem PBI

Os resultados conseguidos com essa abordagem porém, são os melhores possíveis: facilidade de uso, efetividade, e um resultado final sempre funcional com virtualmente nenhuma chance de problemas, conflitos ou falhas de dependência. No geral pesando as desvantagens do maior espaco em disco, as vantagens justificam a popularizacão do formato PBI por usuários típicos do PC-BSD.

 

fonte: fug-br  –  Por P. Tracanelli (FreeBSD Brasil)

Share Button

Melhorando a segurança no FreeBSD – Parte 2

Posted by gondim | Posted in Dicas, FreeBSD, Segurança | Posted on 20-05-2012

Tags:, , , , ,

0

Dando continuidade nas melhorias de segurança no FreeBSD veremos mais algumas coisas que não foram abordadas aqui. O usuário root sempre foi um cara muito privilegiado e por isso devemos evitá-lo ao máximo e também não permitir que outras pessoas usem ele. Logicamente que segurança física sempre foi o Calcanhar de Aquiles da Segurança da Informação, mas podemos tomar alguns cuidados. Abaixo vamos seguir algumas dicas:

Remoção do usuário “toor”. Não tem utilidade para o sistema e possui “UID 0” que é um perigo para o sistema. Reparem que o perigo não está no nome do usuário e sim no UID (User ID) que sendo 0, é o grande perigo. Só o nome root não seria perigoso se o UID dele fosse diferente de 0.

Para remover o toor basta executar: vipw ir na linha abaixo e apagar teclando “dd”, depois “shift :” e “wq!” para sair gravando. Bem precisa conhecer um pouco de vi.  🙂

toor:*:0:0::0:0:Bourne-again Superuser:/root:

Outra coisa é retirar o shell de todos os usuários que não necessitarem de shell. Serviços não precisam que seus usuários tenham shell. Para isso verifique como está o seu /etc/master.password com o vipw. No FreeBSD 9.0 eles já são instalados com /usr/sbin/nologin como shell das contas. Mas quem ainda usa versões anteriores vão precisar alterar. Deve ficar parecido com o exemplo abaixo:

# $FreeBSD: release/9.0.0/etc/master.passwd 218047 2011-01-28 22:29:38Z pjd $
#
root:$1$ensO.a5U$02Vji3o598eieKtAf6Lpm.:0:0::0:0:Charlie &:/root:/usr/local/bin/bash
daemon:*:1:1::0:0:Owner of many system processes:/root:/usr/sbin/nologin
operator:*:2:5::0:0:System &:/:/usr/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source:/:/usr/sbin/nologin
tty:*:4:65533::0:0:Tty Sandbox:/:/usr/sbin/nologin
kmem:*:5:65533::0:0:KMem Sandbox:/:/usr/sbin/nologin
games:*:7:13::0:0:Games pseudo-user:/usr/games:/usr/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/usr/sbin/nologin
man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/usr/sbin/nologin
sshd:*:22:22::0:0:Secure Shell Daemon:/var/empty:/usr/sbin/nologin
smmsp:*:25:25::0:0:Sendmail Submission User:/var/spool/clientmqueue:/usr/sbin/nologin
mailnull:*:26:26::0:0:Sendmail Default User:/var/spool/mqueue:/usr/sbin/nologin
bind:*:53:53::0:0:Bind Sandbox:/:/usr/sbin/nologin
proxy:*:62:62::0:0:Packet Filter pseudo-user:/nonexistent:/usr/sbin/nologin
_pflogd:*:64:64::0:0:pflogd privsep user:/var/empty:/usr/sbin/nologin
_dhcp:*:65:65::0:0:dhcp programs:/var/empty:/usr/sbin/nologin
uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/local/libexec/uucp/uucico
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/usr/sbin/nologin
www:*:80:80::0:0:World Wide Web Owner:/nonexistent:/usr/sbin/nologin
hast:*:845:845::0:0:HAST unprivileged user:/var/empty:/usr/sbin/nologin
nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/usr/sbin/nologin

Reparem que só o root tem shell que no meu caso é o bash.

Próxima melhoria seria aumentar a segurança da senha do root trocando md5 para blowfish. Para essa tarefa precisamos editar o arquivo /etc/login.conf:

default:\
        :passwd_format=md5:\

Para:

default:\
        :passwd_format=blf:\

Após alterar o arquivo login.conf precisamos rodar o seguinte comando para que seja gerado o /etc/login.conf.db, cujo arquivo é o que o sistema realmente usa.

# cap_mkdb /etc/login.conf

Mas não acabamos com a senha ainda. Após feito isso precisamos alterar novamente as senhas que desejamos para que essas agora estejam em blowfish e isso pode ser feito com o comando passwd. Reparem na diferença dos tipos:

MD5:

root:$1$9kaWUo5i$fIoOwZFsBsZG9WR/.nqhh1:0:0::0:0:Charlie &:/root:/usr/local/bin/bash

Blowfish:

root:$2a$04$qXWwmvWbpMrp7qpwDbxX/uVccYR3jfhET/hD1U2h9ZN7QyP13yW26:0:0::0:0:Charlie &:/root:/usr/local/bin/bash

Blowfish é bem mais forte (seguro) que md5. Obs: antigamente se usava o /etc/auth.conf para essa configuração.

Outra coisa boa é definir um idle timeout para o root, no caso de você acidentalmente esquecer o usuário root logado no servidor. Se você estiver usando bash como shell, basta adicionar essa variável em /etc/profile:

TMOUT=300

A variável acima trabalha em segundos, ou seja, se o root ficar sem fazer nada por 5 minutos, automaticamente este é deslogado.

Se estiver usando csh como shell, adicione a seguinte linha em /etc/csh.login:

set autologout=5

O autologout trabalha em minutos e vai fazer a mesma função do TMOUT no csh.

Se usa outro shell você precisará pesquisar se este possui uma variável de controle para essa finalidade.

Infelizmente no sh não existe um equivalente para essa finalidade.

Continuando com a nossa melhoria de segurança se você não quiser que alguém logue como root na console do seu servidor podemos editar o arquivo /etc/ttys cujo exemplo está abaixo:

# If console is marked “insecure”, then init will ask for the root password
# when going to single-user mode.
console none                            unknown off secure
#
ttyv0   “/usr/libexec/getty Pc”         xterm   on  secure
# Virtual terminals
ttyv1   “/usr/libexec/getty Pc”         xterm   on  secure
ttyv2   “/usr/libexec/getty Pc”         xterm   on  secure
ttyv3   “/usr/libexec/getty Pc”         xterm   on  secure
ttyv4   “/usr/libexec/getty Pc”         xterm   on  secure
ttyv5   “/usr/libexec/getty Pc”         xterm   on  secure
ttyv6   “/usr/libexec/getty Pc”         xterm   on  secure
ttyv7   “/usr/libexec/getty Pc”         xterm   on  secure
ttyv8   “/usr/local/bin/xdm -nodaemon”  xterm   off secure
# Serial terminals
# The ‘dialup’ keyword identifies dialin lines to login, fingerd etc.
ttyu0   “/usr/libexec/getty std.9600”   dialup  off secure
ttyu1   “/usr/libexec/getty std.9600”   dialup  off secure
ttyu2   “/usr/libexec/getty std.9600”   dialup  off secure
ttyu3   “/usr/libexec/getty std.9600”   dialup  off secure
# Dumb console
dcons   “/usr/libexec/getty std.9600”   vt100   off secure

Basta mudar a coluna secure para insecure conforme abaixo:

# If console is marked “insecure”, then init will ask for the root password
# when going to single-user mode.
console none                            unknown off insecure
#
ttyv0   “/usr/libexec/getty Pc”         xterm   on  insecure
# Virtual terminals
ttyv1   “/usr/libexec/getty Pc”         xterm   on  insecure
ttyv2   “/usr/libexec/getty Pc”         xterm   on  insecure
ttyv3   “/usr/libexec/getty Pc”         xterm   on  insecure
ttyv4   “/usr/libexec/getty Pc”         xterm   on  insecure
ttyv5   “/usr/libexec/getty Pc”         xterm   on  insecure
ttyv6   “/usr/libexec/getty Pc”         xterm   on  insecure
ttyv7   “/usr/libexec/getty Pc”         xterm   on  insecure
ttyv8   “/usr/local/bin/xdm -nodaemon”  xterm   off insecure
# Serial terminals
# The ‘dialup’ keyword identifies dialin lines to login, fingerd etc.
ttyu0   “/usr/libexec/getty std.9600”   dialup  off insecure
ttyu1   “/usr/libexec/getty std.9600”   dialup  off insecure
ttyu2   “/usr/libexec/getty std.9600”   dialup  off insecure
ttyu3   “/usr/libexec/getty std.9600”   dialup  off insecure
# Dumb console
dcons   “/usr/libexec/getty std.9600”   vt100   off insecure

Cuidado com a linha “console none                            unknown off insecure” porque se você colocar ela como insecure quando precisar entrar em sigle mode para recuperar algo no sistema, será pedido a senha de root. Isso pode ser ruim se caso estiver tentando recuperar senhas. Logo ficará ao seu critério colocar a console como insecure. Qualquer tty definida como insecure não será possível acessar como root.

Agora vamos restringir certos acessos, mas chequem se alguma aplicação de vocês precisará de acesso à um desses arquivos em específico:

# chflags noschg /usr/bin/crontab

# echo “root” > /var/cron/allow
# echo “root” > /var/at/at.allow
# chmod o= /etc/crontab
# chmod o= /usr/bin/crontab
# chmod o= /usr/bin/at
# chmod o= /usr/bin/atq
# chmod o= /usr/bin/atrm
# chmod o= /usr/bin/batch

# chflags schg /usr/bin/crontab

Alguns arquivos já tem vindo com proteções usando chflags e por isso precisamos removê-las para alterar as permissões e depois adiciona-las novamente. Para ver se algum arquivo está com chflags setado use o ls com o parâmetro “o”. Abaixo um exemplo:

# ls -laAGo/usr/bin/crontab
-r-sr-xr-x  1 root  wheel  schg  27404 Feb  9 15:17 /usr/bin/crontab

Repare na quinta coluna a flag schg que diz que esse arquivo é imutável.

Continuando… acima estamos restringindo o uso do cron e at somente para o root. Nenhum outro usuário do sistema poderá usá-los. Também estamos removendo as permissões de usuários regulares dos arquivos pertinentes ao cron e at.

Abaixo mais restrições aos usuários regulares para que não acessem alguns conteúdos pois não deveriam ser de interesse deles:

# chmod o= /etc/fstab
# chmod o= /etc/ftpusers
# chmod o= /etc/group
# chmod o= /etc/hosts
# chmod o= /etc/hosts.allow
# chmod o= /etc/hosts.equiv
# chmod o= /etc/hosts.lpd
# chmod o= /etc/inetd.conf
# chmod o= /etc/login.access
# chmod o= /etc/login.conf
# chmod o= /etc/newsyslog.conf
# chmod o= /etc/rc.conf
# chmod o= /etc/ssh/sshd_config
# chmod o= /etc/sysctl.conf
# chmod o= /etc/syslog.conf
# chmod o= /etc/ttys

Quanto aos logs também pode ser feito uma coisa interessante com chflags mas tenham em mente que fazendo isso o rotacionamento de logs não funcionará mais. Minha sugestão, se você quiser uma boa segurança nesse aspecto, é você montar um servidor de logs e configurar os demais servidores para enviarem os logs para esse servidor. Aí sim nesse servidor específico você poderia até fazer o que está abaixo:

# chmod o= /var/log
# chflags sappnd /var/log
# chflags sappnd /var/log/*

Com essa conf acima, os arquivos de log estarão em append only e não poderá ser removida qualquer linha deles, somente adicionada.

Mais restrições à usuários regulares para que não tenham informações importantes do sistema como quem está logado, listar jails, quem logou e por aí vai:

# chmod o= /usr/bin/users
# chmod o= /usr/bin/w
# chmod o= /usr/bin/who
# chmod o= /usr/bin/lastcomm
# chmod o= /usr/sbin/jls
# chmod o= /usr/bin/last
# chmod o= /usr/sbin/lastlogin

Desabilitar o uso do rlogin e do rsh:

# chflags noschg /usr/bin/rlogin /usr/bin/rsh

# chmod ugo= /usr/bin/rlogin
# chmod ugo= /usr/bin/rsh

# chflags schg /usr/bin/rlogin /usr/bin/rsh

O syslogd vem por default habilitado para receber logs e por isso abre uma porta de acesso ao mesmo. Como falei anteriormente acho mais seguro fazer isso em um servidor separado e por isso vamos desabilitar essa função no syslogd local e deixá-la habilitada no servidor de logs. O syslogd continuará funcionando do mesmo jeito só não haverá nenhuma porta escutando uma conexão.

# echo ‘syslogd_flags=”-ss”‘ >> /etc/rc.conf

Vamos partir agora para variáveis da systcl. Existem 2 variáveis que habilitam o recurso log_in_vain que é muito útil quando queremos saber se alguém está tentando acessar alguma porta de serviço que não esteja habilitada no nosso servidor. Para habilitar é muito simples adicione as linhas abaixo no seu /etc/sysctl.conf. Isso também pode ser habilitado pelo /etc/rc.conf, para isso consulte o /etc/defaults/rc.conf.

sysctl net.inet.tcp.log_in_vain=1
sysctl net.inet.udp.log_in_vain=1

Fazendo um teste de uma outra máquina, tentei fazer um telnet na máquina protegida (10.255.0.12) na porta 9998/tcp o que resultou no log abaixo:

/var/log/messages:May 20 11:52:11 protheus kernel: TCP: [192.168.255.1]:59486 to [10.255.0.12]:9998 tcpflags 0x2<SYN>; tcp_input: Connection attempt to closed port

Agora vamos bloquear que outros usuários possam ver processos de outros usuários, colocando a linha abaixo também no /etc/sysctl.conf:

security.bsd.see_other_uids=0

Muitas das coisas do post acima, retirei dessa documentação do Jon LaBass. Pelo menos as que achei mais interessantes e adicionei algumas mudanças pois uma coisa que foi citada em seu texto, ainda não existe implementação no FreeBSD que foi o caso do idletime no /etc/login.conf. Ela existe para uso de aplicações de terceiros mas não na base do FreeBSD, ou seja, o fato de setar ela não irá funcionar e por isso usei outros recursos como o TMOUT e o autologout. Existem outras alterações citadas por ele mas preferi expor apenas as que me interessei.

É isso aí pessoal e até a próxima.

Não deixem de ler o meu primeiro post sobre Melhorando a Segurança no FreeBSD com securelevel + chflags aqui.

Share Button

Aviso importante! Mudanças na versão do PHP 5 em /usr/ports/lang/php5

Posted by gondim | Posted in Dicas, FreeBSD | Posted on 18-05-2012

Tags:, ,

0

Para aqueles que estão usando o PHP 5.3 instalado à partir do /usr/ports/lang/php5 perceberão que após um “portsnap fetch update” a versão mudará para o PHP 5.4.3. Cuidado na hora de atualizar o PHP para não trocar de versão acidentalmente. O PHP 5.3 agora encontra-se em:

/usr/ports/lang/php53

Os desenvolvedores afirmam que são poucas as incompatibilidades entre versão 5.3 e a 5.4. Mas todo cuidado é bom e por isso aqui está a página informando as incompatibilidades.

As novidades dessa nova versão podem ser vistas aqui.

É isso aí pessoal. Aqui no meu sistema eu mudei os pacotes php5-… para php53-… usando o portmaster citado nesse post.

Grande abraço aos leitores daqui do blog.

 

Share Button

Gerenciando seus pacotes no FreeBSD com o portmaster

Posted by gondim | Posted in Dicas, FreeBSD, Software Livre | Posted on 18-05-2012

Tags:, ,

12

Uma coisa que sempre foi complicada quando trabalhamos com pacotes compilados, é a famosa dependência. Quando instalamos uma aplicação pelo ports, o mesmo se encarrega de baixar, compilar e instalar todas as dependências que aquela aplicação necessita. Dependendo da aplicação e dependência ainda podem aparecer janelas de configurações de opções de compilação para aquele determinado pacote e aí dependendo das marcações, mais dependências poderão surgir no contexto. Até aqui tudo bem, o problema maior é quando você precisa atualizar uma lib ou aplicação que envolverá atualizar outras aplicações da sua dependência. Para você ter uma idéia do que estou dizendo vou pegar como exemplo a libpcre e usar o comando “pkg_info -R” para mostrar quais pacotes dependem dele:

# pkg_info -R pcre-8.30_2
Information for pcre-8.30_2:

Required by:
ap22-mod_auth_mysql_another-3.0.0_4
ap22-mod_wsgi-2.8_2
apache-2.2.22_5
pecl-APC-3.1.9_1
pecl-intl-1.1.2_3
pecl-pdflib-2.1.8_1
phpMyAdmin-3.4.10.2
postfixadmin-2.3.5
roundcube-0.7,1
php5-5.3.13
php5-zip-5.3.13
php5-zlib-5.3.13
php5-mbstring-5.3.13
php5-gettext-5.3.13
php5-mysqli-5.3.13
php5-gd-5.3.13
php5-imap-5.3.13
php5-xml-5.3.13
php5-openssl-5.3.13
php5-session-5.3.13
php5-iconv-5.3.13
php5-pspell-5.3.13
php5-dom-5.3.13
php5-sqlite-5.3.13
php5-json-5.3.13
php5-ldap-5.3.13
php5-hash-5.3.13
php5-ctype-5.3.13
php5-bz2-5.3.13
php5-mysql-5.3.13
php5-xmlrpc-5.3.13
php5-filter-5.3.13
php5-mcrypt-5.3.13
postfix-2.8.10,1

Isso quer dizer que se eu atualizar essa lib, terei que recompilar todos esses pacotes que dependem dela. Imagine o trabalho e agora imagine ter que fazer isso em mais de um servidor. Uns 2 anos atrás isso me assombrou pois na época tentei usar o portupgrade e não me adaptei muito bem. Foi quando conheci o portmaster e realmente fiquei maravilhado com essa ferramenta fabulosa escrita em shell script por Douglas Barton.

Para usarmos o portmaster precisamos primeiramente instala-lo:

# cd /usr/ports/ports-mgmt/portmaster

# make install clean

# rehash <- se tiver usando csh

O man portmaster pode lhe apresentar todas as opções disponíveis e por isso vou mostrar apenas algumas básicas aqui:

Instalando um pacote:

# portmaster lang/php5-extensions   <- esse comando fará a instalação do PHP5 e as extensões que você selecionar para ele.

Excluir um pacote:

# portmaster -e php5-bz2-5.3.13   <- nesse caso estou querendo excluir esse pacote php5-bz2

Substituir uma versão de pacote já instalada por outra:

# portmaster -o /usr/ports/mail/postfix28 postfix-2.7.8_1,1   <- nesse exemplo estou substituindo o postfix 2.7 que já está instalado no meu sistema, pelo postfix 2.8. Repare que o parâmetro “-o” especifica o local onde se encontra o novo pacote que será colocado no lugar do anterior.

Atualizar e recompilar todos os pacotes instalados:

# portmaster -a -f   <- quando você quiser atualizar e recompilar todos os pacotes instalados no seu sistema. Dependendo da quantidade de pacotes isso poderá demorar um bocado.

Atualizar um pacote e todas as suas dependências e ainda apagando os distfiles:

# portmaster -d -Rf databases/rrdtool    <- nesse caso vai atualizar e recompilar o pacote rrdtool e todas as suas depências. O “-d” vai dizer para o portmaster apagar os distfiles.

Para excluir um pacote da atualização:

# portmaster -a -f -x roundcube   <- aqui vou atualizar todos os pacotes exceto o pacote roundcube

Bem é isso pessoal. Mais detalhes estudem o man do portmaster.

Ah! Não esqueçam de fazer um “portsnap fetch update” antes de usar o portmaster.  🙂

Share Button

FreeBSD no desktop. Por que não?

Posted by gondim | Posted in Dicas, FreeBSD, Tecnologia | Posted on 18-05-2012

Tags:, , ,

2

Hoje venho falar de algo que não é novidade no mundo BSD mas aqui, para nós, não é tão utilizado quanto uma certa distribuição GNU/Linux. FreeBSD sempre foi um sistema voltado para servidores mas nada impedia que fosse instalado em desktops. Como sabemos existem muitos pacotes e configurações necessárias para que o sistema se torne mais amigável. Para esse propósito surgiu um projeto como o PC-BSD. O projeto tem o objetivo de ser usado no ambiente desktop tornando-o mais simples ao usuário. Se gostas de um desafio e conhecer novos ambientes por que não experimentar esse sistema? Um outro projeto destinado à desktops mas de uma forma mais Hacker, é o MidnightBSD. Não sou daqueles que afirmam que um sistema é melhor ou pior que o outro mas incentivo as pessoas à experimentarem e verem se gostam. Isso sim é liberdade, poder usar aquilo que gostamos. Se o que gostamos é pago ou free aí é outro problema. Mas liberdade, para mim, é ser livre para poder escolher. Ser obrigado à algo não é e nunca será sinônimo de liberdade.

Vamos à algumas características de cada Desktop:

PC-BSD: atualmente na versão 9.0, esse projeto é o mesmo FreeBSD e acompanha seu versionamento oficial. Possui todos os recursos existentes no FreeBSD mas também tem umas características únicas, como seu sistema de empacotamento próprio conhecido como PBI (Push Button Installer). Os arquivos .pbi, encontrados no repositório AppCafe™,  facilitam a instalação de novos pacotes e a atualização do sistema como um todo. Uma comparação seria a semelhança com o Central de Programas do Ubuntu Linux. Também pode ser instalado com KDE, Gnome e outros gerenciadores de janelas.

Umas imagens de desktops com PC-BSD:

MidnightBSD: atualmente na versão 0.3. O MidnightBSD tem uma característica bem diferenciada do PC-BSD pois este surgiu de um fork do FreeBSD 6.1 beta mas a versão atual foi baseada no FreeBSD 7.0. Este sistema possui também tecnologia proveniente do DragonFly, OpenBSD e NetBSD. A instalação não é amigável como a do PC-BSD. Eu vejo o MidnightBSD para um público desktop Hacker vamos dizer assim.  🙂

Eles criaram um sistema de gerenciamento de pacotes chamado mports com o intuito de facilitar a nossa vida e muito parecido em sua sintaxe com o apt-get do GNU/Debian. Exemplos: mport update, mport search <string>, mport info <pacote>, mport install <pacote> e outros mais.

 

 

 

 

 

 

 

Bem, agora é com vocês e boa diversão.

Share Button

FreeBSD Relatório de Status Trimestral Janeiro – Março de 2012

Posted by gondim | Posted in FreeBSD, Software Livre, Tecnologia | Posted on 13-05-2012

Tags:

10

Este relatório abrange FreeBSD projetos relacionados entre janeiro e março 2012. É o primeiro dos quatro relatórios previstos para 2012. Este trimestre foi marcado por liberar a próxima grande versão do FreeBSD, 9.0, que foi finalmente lançada no início de Janeiro de 2012. O FreeBSD Projeto dedica o FreeBSD 9.0-RELEASE para a memória de Dennis M. Ritchie, um dos fundadores do Sistema Operacional UNIX. Nossa equipe de engenharia de lançamento esteve também ocupada com a preparação da 8.3-RELEASE, que foi publicamente anunciada em abril.

Obrigado a todos os reporters pelo excelente trabalho! Este relatório contém 27 entradas e nós esperamos que você goste de lê-lo.

Por favor, note que o prazo para submissões cobrindo o período entre abril e junho de 2012 é 15 de julho de 2012.

O texto abaixo está em sua íntegra, em inglês e os e-mails foram ofuscados:

Projects

     * FreeBSD Services Control
     * GNU-Free C++11 Stack
     * Growing filesystems online
     * The FreeNAS Project

User-land Programs

     * Clang Replacing GCC in the Base System
     * Replacing the Regular Expression Code
     * The bsdconfig(8) utility

FreeBSD Team Reports

     * Release Engineering Team Status Report
     * The FreeBSD Foundation Team Report

Kernel

     * DTrace Probes for the linuxulator
     * HDMI/DisplayPort Audio Support in HDA Sound Driver (snd_hda)
     * Improved hwpmc(9) Support for MIPS
     * isci(4) SAS Driver

Network Infrastructure

     * Atheros 802.11n Support
     * IPv6 Performance Analysis
     * Multi-FIB: IPv6 Support and Other Enhancements

Documentation

     * The FreeBSD Japanese Documentation Project

Architectures

     * FreeBSD/arm on Various TI Boards
     * FreeBSD/powerpc on Freescale QorIQ DPAA
     * NAND File System, NAND Flash Framework, NAND Simulator
     * Porting DTrace to MIPS and ARM

Ports

     * A New linux_base Port Based Upon CentOS
     * BSD-licensed sort Utility (GNU sort Replacement)
     * KDE/FreeBSD
     * Perl Ports Testing
     * The FreeBSD Haskell Ports
     * The FreeBSD Ports Collection
     __________________________________________________________________

A New linux_base Port Based Upon CentOS

   Contact: Alexander Leidinger <netchild at FreeBSD.org>

   We got a PR with a linux_based port which is based upon CentOS 6.
   Currently this can only be used as a test environment, as it depends
   upon a more recent linux kernel version, than the linuxulator provides.

   As of this writing, I'm in the process of preparing a commit of this
   port.

Open tasks:

    1. Repocopy by portmgr.
    2. Add conflicts in other linux_base ports.
    3. Commit the CentOS based one.
    4. Some cleanup.
     __________________________________________________________________

Atheros 802.11n Support

   URL: http://wiki.FreeBSD.org/AdrianChadd/AtherosTxAgg
   URL: http://wiki.FreeBSD.org/dev/ath(4)

   Contact: Adrian Chadd <adrian at FreeBSD.org>

   802.11n station and hostap support is now fully functional, sans
   correct hostap side power saving. TX aggregation and TX BAR handling is
   implemented.

   Station chip power saving is not implemented at all yet, it's not in
   the scope of this work.

   Testers should disable bgscan (-bgscan) as scan/bgscan will simply drop
   any traffic in the TX/RX queues, causing potential traffic stalls.

Open tasks:

    1. Fix up hostap side power save handling.
    2. Implement filtered frames support in the driver.
    3. Fix scan/bgscan to correctly buffer and retransmit frames when
       going off channel, so frames are not just "dropped" - this causes
       issues in the aggregation sessions and may cause traffic stalls.
    4. Test/fix any issues with adhoc 802.11n support.
     __________________________________________________________________

BSD-licensed sort Utility (GNU sort Replacement)

   URL: http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/textproc/bsdsort/
   URL:
   http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html

   Contact: Oleg Moskalenko <oleg.moskalenko at citrix.com>
   Contact: Gábor Kövesdán <gabor at FreeBSD.org>

   Currently the BSD sort reached usable stable stage. It is stable, it is
   as fast as the GNU sort, and it supports multi-byte locales (this is
   something that GNU sort does not do correctly). BSD sort has all
   features of GNU sort 5.3.0 (version included into FreeBSD) with some
   extra features and bug fixes.

Open tasks:

    1. Add BSD sort into HEAD as an alternative, installed as bsdsort. If
       proven to work as expected, change it to the default sort version
       and remove GNU sort.
    2. Investigate the possibility of a multi-threaded sort implementation
       and implement it, if it proves more efficient.
    3. Upgrade BSD sort features to include some obscure new features in
       the latest GNU sort version 8.15.
     __________________________________________________________________

Clang Replacing GCC in the Base System

   URL: http://wiki.FreeBSD.org/BuildingFreeBSDWithClang

   Contact: Brooks Davis <brooks at FreeBSD.org>
   Contact: David Chisnall <theraven at FreeBSD.org>
   Contact: Dimitry Andric <dim at FreeBSD.org>
   Contact: Ed Schouten <ed at FreeBSD.org>
   Contact: Pawel Worach <pawel.worach at gmail.com>
   Contact: Roman Divacky <rdivacky at FreeBSD.org>

   Both FreeBSD 10.0-CURRENT and 9.0-STABLE now have Clang 3.0 release
   installed by default. At least on 10.0-CURRENT, both world and the
   GENERIC kernel can be completely built without any -Werror warnings.
   This may not be the case for all custom kernel configurations yet.

   As of r231057, there is a WITH_CLANG_EXTRAS option for src.conf(5),
   which will enable a number of additional LLVM and Clang tools, such as
   'llc' and 'opt'. These tools are mainly useful for people that want to
   manipulate LLVM bitcode (.bc) and LLVM assembly language (.ll) files,
   or want to tinker with LLVM and Clang themselves.

   Also, as of r232322, there is a WITH_CLANG_IS_CC option for
   src.conf(5), which will install Clang as /usr/bin/cc, /usr/bin/c++ and
   /usr/bin/cpp, making it the default system compiler. Unless you also
   use the WITHOUT_GCC option, gcc will still be available as
   /usr/bin/gcc, /usr/bin/g++ and /usr/bin/gcpp.

   The intent is to switch on this option by default rather sooner than
   later, so we can start preparing for shipping 10.0-RELEASE with Clang
   as as the default system compiler, and deprecating gcc.

   In other news, we will import a newer snapshot of Clang soon, since
   upstream LLVM/Clang has already announced their 3.1 release will be
   branched April 16, 2012. Most likely, the actual 3.1 release will be
   follow a few weeks later, after which we will do another import.

   Last but not least, there are many ports people working on making our
   ports compile properly with Clang. Fixes are checked in on a very
   regular basis now, and full exp-runs with Clang are also done fairly
   regularly. Of course, there are always a few difficult cases,
   especially with very old software that will not even compile with newer
   versions of gcc, let alone clang.

Open tasks:

    1. One of the most important tasks at the moment is to actually build
       and run your entire FreeBSD system with Clang, as much as possible.
       Any compile-time or run-time problems should be reported to the
       appropriate mailing list, or filed as a PR. If you have patches
       and/or workarounds, that would be even better.
    2. Clang should have gotten better support for cross-compiling after
       3.0, so as soon as a 3.1 version is imported, we will need to look
       at ways to get the FreeBSD world and kernels to cross-compile. This
       is mainly of use for ARM and MIPS, which are architectures you
       usually do not want to build natively on.
    3. Help to make unwilling ports build with Clang is always needed, and
       greatly appreciated. Please mail the maintainer of your favorite
       port with patches, or file PRs.
     __________________________________________________________________

DTrace Probes for the linuxulator

   Contact: Alexander Leidinger <netchild at FreeBSD.org>

   Recently DTrace in the kernel was improved to be able to load kernel
   modules with static dtrace providers after the dtrace modules. This
   allows me to commit my linuxulator specific static provider work to
   -CURRENT.

   Together with the linuxulator DTrace probes I developed some D scripts
   to check various code paths in the linuxulator. Those scripts check
   various error cases which may be interesting to verify userland code,
   but also linuxulator internals like locks.

   As of this writing I'm in the process of updating a test machine to a
   more recent -current to prepare the commit.
     __________________________________________________________________

FreeBSD Services Control

   URL: http://people.FreeBSD.org/~trhodes/fsc/

   Contact: Tom Rhodes <trhodes at FreeBSD.org>

   After a while of moving and getting a new job, I finally got back to
   this project (also thanks to several submissions by Julian Fagir), a
   new version has been uploaded along with a short description page. The
   current version supports more options, a configuration file, and
   updated rc.d script. It also includes manual page updates and an
   optional debugging mode.
     __________________________________________________________________

FreeBSD/arm on Various TI Boards

   URL: http://svnweb.FreeBSD.org/base/projects/armv6/sys/arm/ti/

   Contact: Ben Gray <bgray at FreeBSD.org>
   Contact: Olivier Houchard <cognet at FreeBSD.org>
   Contact: Damjan Marion <dmarion at FreeBSD.org>
   Contact: Oleksandr Tymoshenko <gonzo at FreeBSD.org>

   The goal of this project is to get FreeBSD running on various popular
   boards that use TI-based SoCs like OMAP3, OMAP4, AM335x. Project covers
   some ARM generic Cortex-A components: GIC (Generic Interrupt
   Controller), PL310 L2 Cache Controller and SCU.

   PandaBoard (TI OMAP4430) and PandaBoard ES (OMAP4460) Dual core ARM
   Cortex-A9 board support includes: USB, onboard Ethernet over USB, GPIO,
   I2C and MMC/SD card drivers. Board works in multiuser mode over NFS
   root.

   BeagleBone (TI AM3358/AM3359) single core ARM Cortex-A8 based board
   support currently includes: Ethernet, L2 cache, GPIO, I2C. Board works
   in multiuser mode over NFS root.

Open tasks:

    1. Completing missing peripherals: DMA, SPI, MMC/SD, Video, Audio.
    2. Completing SMP support and testing.
    3. Importing BeagleBoard (OMAP3) code to SVN.
    4. Improving overall stability and performance.
     __________________________________________________________________

FreeBSD/powerpc on Freescale QorIQ DPAA

   URL:
   http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P2040
   URL:
   http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P3041
   URL:
   http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P5020
   URL:
   http://www.freescale.com/webapp/sps/site/homepage.jsp?code=64BIT&fsrch=
   1&sr=1

   Contact: Michal Dubiel <md at semihalf.com>
   Contact: Rafal Jaworowski <raj at semihalf.com>
   Contact: Piotr Ziecik <kosmo at semihalf.com>

   This work is bringing up the FreeBSD on Freescale QorIQ Data Path
   Acceleration Architecture (DPAA) system-on-chips along with device
   drivers for integrated peripherals. Since the last status report, the
   following support has been added:
     * Ethernet (full network functionality using Regular Mode of DPAA
       infrastructure)
     * QorIQ P5020 SoC (e5500 core in legacy 32-bit mode)
     * P5020 QorIQ Development System support
     * Initial support for Enhanced SDHC

   The next step is:
     * e5500 core in native 64-bit mode

   Related publications:
     * Michal Dubiel, Piotr Ziecik, "FreeBSD on Freescale QorIQ Data Path
       Acceleration Architecture Devices", AsiaBSDCon, March 2012, Tokyo,
       Japan.
     __________________________________________________________________

GNU-Free C++11 Stack

   Contact: David Chisnall <theraven at FreeBSD.org>

   Since the last status report, the combination of libc++ and libcxxrt
   has received some additional testing and gained some new features
   including support for ARM EABI. With clang 3.1, we now pass all of the
   C++11 atomics tests.

   The xlocale implementation (required for libc++) has been tested with a
   variety of ports that were originally written for the Darwin
   implementation, and bugs that this testing uncovered have been fixed.
   This should be released in 9.1.

   In -CURRENT, we are now building libsupc++ as a shared library. This
   provides the ABI layer and building it as a shared library means that
   we can replace it with libcxxrt easily. If you are running -CURRENT,
   please try using libmap.conf to enable libcxxrt instead of libsupc++.

   If libstdc++ is using libcxxrt, you can now link against both libraries
   that are using libstdc++ and libc++, making the migration slightly
   easier, although you cannot pass STL objects between libraries using
   different STL versions.

   We still need a replacement for some parts of libgcc_s and for the
   linker, but we're on track for a BSD licensed C++ stack in 10.0.

Open tasks:

    1. Test ports with libc++. Hopefully most will Just Work, but others
       may need patches or have a hard dependency on libstdc++.
    2. Enable building libc++ by default. This is dependent upon building
       with clang, because the version of gcc in the base system does not
       support C++11 and so can not be used to build libc++.
    3. Removing libstdc++ from the base system and making it available
       through ports for backwards compatibility.
     __________________________________________________________________

Growing filesystems online

   Contact: Edward Tomasz Napierala <trasz at FreeBSD.org>

   The goal of this project is to make it possible to grow a filesystem,
   both UFS and ZFS, while it's mounted read-write. This includes changes
   to both filesystems, GEOM infrastructure, and the da(4) driver. For
   testing purposes, I've also added resizing to mdconfig(8) and
   implemented LUN resizing in CAM Target Layer.

   From the system administrator point of view, this makes it possible to
   resize mounted partition using gpart(8) and then resize the filesystem
   on it using growfs(8) - all without unmounting it first; especially
   useful if it's a root filesystem.

   All the functionality works and is in the process of being refined,
   reviewed and merged to HEAD.

   This project is sponsored by The FreeBSD Foundation.

Open tasks:

    1. The write suspension infrastructure (/dev/ufssuspend) implemented
       to make resizing possible makes it also possible to implement
       online tunefs(8) and fsck(8).
    2. Right now, there is no way for a GEOM class to veto resizing --
       classes are notified about resize and they can either adapt, or
       wither. Many classes store their metadata in the last sector,
       though, so resizing a partition containing e.g. gmirror will make
       it inoperable. It would be nice if geom_mirror(4) could veto
       resizing, so the administrator attempting to shoot himself in the
       foot would get a warning.
     __________________________________________________________________

HDMI/DisplayPort Audio Support in HDA Sound Driver (snd_hda)

   Contact: Alexander Motin <mav at FreeBSD.org>

   snd_hda(4) driver got number of improvements to better support
   HDMI/DisplayPort audio, such as:
     * Added fetching EDID-Like Data from the CODEC and video driver,
       describing audio capabilities of the display device.
     * Added setting HDMI/DP-specific CODEC options, such as number of
       channels, speakers configuration and channels mapping.
     * Added support for more multichannel formats. For HDMI and
       DisplayPort device now supported: 2.0, 2.1, 3.0, 3.1, 4.0, 4.1,
       5.0, 5.1, 6.0, 6.1, 7.0 and 7.1 channels.
     * Added support for compressed streams passthrough with data rate
       6.144 - 24Mbps, such as DTS-HD Master Audio or Dolby TrueHD.
     * Added support for HDA bus multiplexing to handle higher data rates
       (up to 92, 184 or more Mbps, depending on hardware capabilities).
       It allows to handle several 192/24/8 LPCM playback streams
       simultaneously.

   Above functionality was successfully tested on NVIDIA GT210 and GT520
   video cards with nvidia-driver-290.10 driver. HDMI audio on older
   NVIDIA ION and Geforce 8300 boards still does not work for unknown
   reason. There are also successful reports about Intel video with latest
   KMS-based drivers. Support for ATI cards is limited to older cards,
   because video driver supporting newer cards does not support HDMI
   audio.

   The code was committed to HEAD and merged to 9-STABLE branch.

   Project sponsored by iXsystems, Inc.

Open tasks:

    1. Make better use of received EDID-Like Data.
    2. Identify and fix problem with older NVIDIA cards.
     __________________________________________________________________

Improved hwpmc(9) Support for MIPS

   Contact: Oleksandr Tymoshenko <gonzo at FreeBSD.org>

   hwpmc(9) for MIPS has been reworked. The changes include:
     * msip24k code was split to CPU-specific and arch-specific parts to
       make adding support for new CPUs easier
     * Added support for Octeon PMC
     * Added sampling support for MIPS in general
     __________________________________________________________________

IPv6 Performance Analysis

   URL: http://people.FreeBSD.org/~bz/bench/

   Contact: Bjoern A. Zeeb <bz at FreeBSD.org>

   IPv6 performance numbers were often seen (significantly) lower on
   FreeBSD when compared to IPv4. Continuing last years IPv6-only kernel
   efforts this project looked at various reasons for this and started
   fixing some.

   As part of the project a benchmark framework was created that could
   carry out various tests including reboots in between runs and gather
   results reproducibly without user intervention. It allows regular
   benchmarking with minimal configuration and easy future extension for
   more benchmarks.

   As a result of the initial analysis, UDP locking and route lookups were
   improved, and delayed checksumming, TSO6 and LRO support for IPv6 were
   implemented. Following this checksum "offload" for IPv6 on loopback was
   enabled and various further individual improvements, both locking and
   general code changes, as well as a reduction of the cache size
   footprint were carried out. Some of the changes were equally applied to
   IPv4.

   Performance numbers on physical and loopback interfaces are on par with
   IPv4 when using offload support with TCP/IPv6, which is a huge
   improvement. UDP and non-offload numbers on IPv6 have generally
   improved but are still lower than on IPv4 and will need future work to
   catch up with a decade of IPv4 benchmarking and code path
   optimizations. UDP IPv6 minimal size send path packets per second (pps)
   numbers however have increased beating IPv4 when sending to a local
   discard device.

   This gets us really close to being able to prefer IPv6 by default
   without causing loopback performance regressions. For physical
   interfaces, cxgb(4) in HEAD already supports IPv6 TCP offload and
   LRO/v6 support was added. To be able to get more test results on
   different hardware, both ixgbe(4) and cxgbe(4) were also updated to
   support TSO6 and LRO with IPv6.

   Some of the insights gained from this work will help upcoming
   discussions on both the lower/link-layer overhaul as well as for the
   mbuf changes to prepare our stack for more, future improvements (ahead
   of time).

   I once again want to thank the FreeBSD Foundation and iXsystems for
   their support of the project, as well as George Neville-Neil for
   providing review.

   Having set the start to close one of the biggest feature parity gaps
   left I will continue to improve IPv6 code paths and hope that we will
   see more contributions and independent results from the community as
   well soon.

Open tasks:

    1. Carefully merge code changes to SVN.
     __________________________________________________________________

isci(4) SAS Driver

   Contact: Jim Harris <jimharris at FreeBSD.org>

   An Intel-supported isci(4) driver, for the integrated SAS controller in
   Intel's C600 chipsets, is now available in head, stable/9, stable/8 and
   stable/7.

   The isci(4) driver will also be part of the FreeBSD 8.3 release.
     __________________________________________________________________

KDE/FreeBSD

   URL: http://FreeBSD.kde.org
   URL: http://FreeBSD.kde.org/area51.php

   Contact: KDE FreeBSD <kde at FreeBSD.org>

   The team has made many releases and upstreamed many fixes and patches.
   The latest round of releases include:
     * KDE SC: 4.7.4 (in ports) and 4.8.0, 4.8.1, 4.8.2 (in area51)
     * Qt: 4.8.0, 4.8.1 (in area51)
     * PyQt: 4.9.1; SIP: 4.13.2 (in area51)
     * KDevelop: 2.3.0; KDevPlatform: 1.3.0 (in area51)
     * Calligra: 2.3.87 (in area51)
     * Amarok: 2.5.0
     * CMake: 2.8.7

   Due to the prolonged port freeze the KDE team has not been able to
   update KDE in Ports as it is considered a intrusive change.

   The team is always looking for more testers and porters so please
   contact us at kde at FreeBSD.org and visit our home page at
   http://FreeBSD.kde.org.

Open tasks:

    1. Testing KDE SC 4.8.2.
    2. Testing KDE PIM 4.8.2.
    3. Testing phonon-gstreamer and phonon-vlc as the phonon-xine backend
       was deprecated (but will remain in the ports for now).
    4. Testing the Calligra beta releases (in the area51 repository).
     __________________________________________________________________

Multi-FIB: IPv6 Support and Other Enhancements

   URL: http://svnweb.FreeBSD.org/base/projects/multi-fibv6/

   Contact: Bjoern A. Zeeb <bz at FreeBSD.org>
   Contact: Alexander V. Chernikov <melifaro at FreeBSD.org>

   In 2008 the multiple forwarding information base (FIB) feature was
   introduced for IPv4 allowing up to 16 distinct forwarding ("routing")
   tables in the kernel. Thanks to the sponsorship from Cisco Systems,
   Inc. this feature is now also available for IPv6 and one of the bigger
   IPv6 feature-parity gaps is closed. The changes have been integrated to
   HEAD, were merged back to stable/9 and stable/8 and will be part of
   future releases for these branches. A backport to stable/7 is also
   available in the project branch. If more than one FIB is requested,
   IPv6 FIBs will be added along the extra IPv4 FIBs without any special
   configuration needed and programs like netstat and setfib, as well as
   ipfw, etc. were extended to seamlessly support the multi-FIB feature on
   both address families.

   Thanks to the help of Alexander V. Chernikov all usage of the multi-FIB
   feature is now using the boot-time variable rather than depending on
   the compile time option. In HEAD this now allows us you to use the
   multi-FIB feature with GENERIC kernels not needing to recompile your
   own anymore. The former kernel option can still be used to set a
   default value if desired. Otherwise the net.fibs loader tunable can be
   used to request more than one IPv6 and IPv4 FIB at boot time.

   Last, routing sockets are now aware of FIBs and will only show the
   routing messages targeted at the FIB attached to. This allows route
   monitor or routing daemons to get selective updates for just a specific
   FIB.
     __________________________________________________________________

NAND File System, NAND Flash Framework, NAND Simulator

   URL: http://svnweb.FreeBSD.org/base/projects/nand/

   Contact: Grzegorz Bernacki <gjb at semihalf.com>
   Contact: Mateusz Guzik <mjg at semihalf.com>

   The NAND Flash stack consists of a driver framework for NAND
   controllers and memory chips, a NAND device simulator and a fault
   tolerant, log-structured file system, accompanied by tools, utilities
   and documentation.

   NAND FS support merged into "nand" project branch:
     * NAND FS filesystem
     * NAND FS userland tools

   NAND Framework and NAND simulator merged into "nand" project
   branch:
     * NAND framework: nandbus, generic nand chips drivers
     * NAND Flash controllers (NFC) drivers for NAND Simulator and Marvell
       MV-78100 (ARM)
     * NAND tool (which allows to erase, write/read pages/oob, etc.

   The next steps include:
     * Fix bugs
     * Merge into HEAD

   Work on this project is supported by the FreeBSD Foundation and Juniper
   Networks.
     __________________________________________________________________

Perl Ports Testing

   URL: http://wiki.FreeBSD.org/Perl#Test_Dependencies

   Contact: Steve Wills <swills at FreeBSD.org>

   Many Perl modules in ports come with test cases included with their
   source. This project's goal is to ensure that all these tests pass.
   Significant progress has been made on this project. The change to build
   perl with -pthread was committed and no issues have been reported. Many
   ports have had missing dependencies added and/or other changes and
   approximately 90% of p5- ports pass tests. Work is being done on
   bringing testing support out of ports tinderbox.

Open tasks:

    1. Finish work on patch to bring testing support to ports.
    2. Add additional support for testing other types of ports such as
       python and ruby.
     __________________________________________________________________

Porting DTrace to MIPS and ARM

   Contact: Oleksandr Tymoshenko <gonzo at FreeBSD.org>

   The major part of DTrace has been ported to MIPS platform. Supported
   ABIs: o32 and n64. n32 has not been tested yet. MIPS implementation
   passes 853 of 927 tests from DTrace test suite.

   The fbt provider and userland DTrace are not supported yet.

   The port to ARM is in progress.

Open tasks:

    1. Userland DTrace support for MIPS.
    2. Investigate amount of effort required for getting fbt provider work
       at least partially.
    3. Find proper solution for cross-platform CTF data generation
       (required for ARM).
     __________________________________________________________________

Release Engineering Team Status Report

   URL: http://www.FreeBSD.org/releng/

   Contact: Release Engineering Team <re at FreeBSD.org>

   On behalf of the FreeBSD Project the Release Engineering Team was are
   pleased to announce the release of the FreeBSD 8.3-RELEASE on April
   18th, 2012.

   With the FreeBSD 8.3 release cycle completed our focus shifts to
   preparing for the FreeBSD 9.1-RELEASE. A schedule will be posted
   shortly, with the release target date set for mid-July 2012.
     __________________________________________________________________

Replacing the Regular Expression Code

   URL: http://svnweb.FreeBSD.org/base/user/gabor/tre-integration/
   URL: http://laurikari.net/tre/
   URL:
   http://www.tdk.aut.bme.hu/Files/TDK2011/POSIX-regularis-kifejezesek1.pd
   f

   Contact: Gábor Kövesdán <gabor at FreeBSD.org>

   Since the last status report, there has been a significant progress in
   optimizing TRE. The multiple pattern heuristic code is mostly finished
   and it distinguishes several different cases to speed up pattern
   matching. It extracts literal fragments from the original patterns and
   uses a multiple pattern matching algorithm to find any occurrence. GNU
   grep uses the Commentz-Walter algorithm, which is an automaton-based
   algorithm, while in this project, it has been decided to use a
   Wu-Manber algorithm, which is more efficient and also easier to
   implement. In the current state, it does not work entirely yet and some
   cases, like the REG_ICASE flag are not yet covered. This is the next
   major step to complete this multiple pattern interface. In the
   development branch, BSD grep is already modified to use this new
   interface so it can be used for testing and debugging purposes.

Open tasks:

    1. Finish multiple pattern heuristic regex matching.
    2. Implement GNU-specific regex extensions.
    3. Test standard-compliance and correct behavior.
     __________________________________________________________________

The bsdconfig(8) utility

   URL: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdconfig/
   URL: http://druidbsd.sf.net/download/bsdconfig/bsdconfig-20120512-1.svg
   URL:
   http://druidbsd.sf.net/download/bsdconfig/bsdconfig-20120512-1i.svg

   Contact: Devin Teske <dteske at FreeBSD.org>
   Contact: Ron McDowell <rcm at fuzzwad.org>

   Approaching 20,000 lines of sh(1) code, the bsdconfig(8) tool is
   approximately 70% complete. Upon completion of this project,
   bsdconfig(8) will represent (in conjunction with already-existing
   bsdinstall(8)) a complete set of utilities capable of purposefully
   deprecating sysinstall(8) in FreeBSD 9 and higher. This project has
   been a labor of love for Ron McDowell and I for over 90 days now and we
   are approaching the completion of this wonderful tool.

Open tasks:

    1. The "installer suite" modules for acquiring/installing binary
       packages and additional distribution sets. Startup services module.
     __________________________________________________________________

The FreeBSD Foundation Team Report

   URL: www.FreeBSDFoundation.org

   Contact: Deb Goodkin <deb at FreeBSDFoundation.org>

   The Foundation sponsored AsiaBSDCon 2012 which was held in Tokyo,
   Japan, March 22-25. We were represented at SCALE on Jan 21 and NELF on
   March 17. This quarter we plan on being at ILF (Indiana LinuxFest)
   April 14th, BSDCan May 11-12, and SELF (Southeast LinuxFest) June 9.

   We are proud to be a gold sponsor of BSDCan 2012, which will be held in
   Ottawa, Canada, May 11-12. We are sponsoring 14 developers to attend
   the conference.

   We kicked off three foundation funded projects -- Growing Filesystems
   Online by Edward Tomasz Napierala, Implementing auditdistd daemon by
   Pawel Jakub Dawidek, and NAND Flash Support by Semihalf.

   We are pleased to announce the addition of George Neville-Neil to our
   board of directors. Deb Goodkin, our Director of Operations, was
   interviewed by bsdtalk.

   We announced a call for project proposals. We will accept proposals
   until April 30th. Please read Project Proposal Procedures to find out
   more.

   FreeBSD 9.0 was released and we are proud to say we funded 7 of the new
   features!
     __________________________________________________________________

The FreeBSD Haskell Ports

   URL: http://wiki.FreeBSD.org/Haskell
   URL: https://github.com/freebsd-haskell/freebsd-haskell/
   URL: https://github.com/freebsd-haskell/hsporter/
   URL: https://github.com/freebsd-haskell/hsmtk/

   Contact: Gábor PÁLI <pgj at FreeBSD.org>
   Contact: Ashish SHUKLA <ashish at FreeBSD.org>

   We are proud announce that the FreeBSD Haskell Team has committed the
   Haskell Platform 2011.4.0.0 update, GHC 7.0.4 update, existing port
   updates, as well new port additions to FreeBSD ports repository, which
   were pending due to freeze for 9.0-RELEASE. Some of the new ports which
   were committed include Yesod, Happstack, wxHaskell, gitit, Threadscope,
   etc. and the count of Haskell ports in FreeBSD Ports tree is now almost
   300. All of these updates will be available as part of upcoming
   8.3-RELEASE.

   We started project hsporter to automate creation of new FreeBSD Haskell
   ports from .cabal file, as well as update existing ports. We also
   published scripts which we were using in the FreeBSD Haskell project
   under the project hsmtk.

Open tasks:

    1. Test GHC to work with clang/LLVM.
    2. Add an option to the lang/ghc port to be able to build it with
       already installed GHC instead of requiring a separate GHC boostrap
       tarball.
    3. Add more ports to the Ports Collection.
     __________________________________________________________________

The FreeBSD Japanese Documentation Project

   URL: http://www.FreeBSD.org/ja/
   URL: http://www.jp.FreeBSD.org/doc-jp/

   Contact: Hiroki Sato <hrs at FreeBSD.org>
   Contact: Ryusuke Suzuki <ryusuke at FreeBSD.org>

   The same as before, the outdated contents in the www/ja subtree were
   updated to the latest versions in the English counterpart. The updating
   work of the outdated translations in the www/ja subtree is almost
   complete. Only the translations of the release documents for old
   releases may be outdated.

   During this period, we translated the 9.0-RELEASE announcement and
   published it in a timely manner. It seems that the Japanese version of
   the release announcement is important for Japanese people as this page
   has frequently been referenced.

   For FreeBSD Handbook, translation work of the "cutting-edge" section is
   still on-going. Some updates in the "printing" and the "linuxemu"
   section were done.

Open tasks:

    1. Further translation work of outdated documents in both
       doc/ja_JP.eucJP and www/ja.
     __________________________________________________________________

The FreeBSD Ports Collection

   URL: http://www.FreeBSD.org/ports/
   URL:
   http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing-ports/
   URL: http://portsmon.FreeBSD.org/index.html
   URL: http://www.FreeBSD.org/portmgr/index.html
   URL: http://blogs.FreeBSDish.org/portmgr/
   URL: http://www.twitter.com/freebsd_portmgr/
   URL: http://www.facebook.com/portmgr

   Contact: Thomas Abthorpe <portmgr-secretary at FreeBSD.org>
   Contact: Port Management Team <portmgr at FreeBSD.org>

   The ports tree slowly climbs above 23,000 ports. The PR count still
   remains at about 1100.

   In Q1 we added 2 new committers, took in 2 commit bits for safe
   keeping, and had one committer return to ports work.

   The Ports Management team have been running -exp runs on an ongoing
   basis, verifying how base system updates may affect the ports tree, as
   well as providing QA runs for major ports updates. Of note, -exp runs
   were done for:
     * Ports validation in the FreeBSD 10 environment
     * Updates to bison, libtool and libiconv
     * Set java/opendjdk6 as default java
     * Tests with clang set as default
     * Update to devel/boost and friends
     * Update of audio/sdl and friends
     * Tests for changes in the ports licensing infrastructure
     * Update to devel/ruby1[8|9]
     * Update to postresql
     * Update to apr
     * Checks for new x11/xorg
     * Security update to security/gnutls
     * Ongoing validation of infrastructure with pkgng

   A lot of focus during this period was put into getting the ports tree
   into a ready state for FreeBSD 8.3, including preparing packages for
   the release.

   Beat Gaetzi has been doing ongoing tests with the ports tree to ensure
   a smooth transition from CVS to Subversion.

Open tasks:

    1. Looking for help getting ports to build with clang.
    2. Looking for help with Tier-2 architectures.
    3. ports broken by src changes.
    4. ports failing on pointyhat.
    5. ports failing on pointyhat-west.
    6. ports that are marked as BROKEN.
    7. When did that port break?
    8. Most ports PRs are assigned, we now need to focus on testing,
       committing and closing.
     __________________________________________________________________

The FreeNAS Project

   URL: http://www.FreeNAS.org

   Contact: Josh Paetzel <jpaetzel at FreeBSD.org>
   Contact: Xin Li <delphij at FreeBSD.org>

   FreeNAS 8.0.4 was released last month, which marks the end of the 8.0.x
   branch in FreeNAS.

   FreeNAS 8.2.0 is in BETA currently, and will hopefully be released by
   the end of April.

   It features a number of improvements over the 8.0.x line, including
   plugin support, (the ability to run arbitrary software in jails), as
   well as better integration between command line ZFS and the GUI.

   Once 8.2.0 is out it will be quickly followed up with 8.3.0, which will
   include a number of driver updates as well as the long awaited ZFS v28.
     __________________________________________________________________

         (c) 1995-2012 The FreeBSD Project. All rights reserved.

 

Share Button