Tech Force - blog sobre tecnologia

Se você já instalou OpenJDK 8 para poder usar o home banking do Banco do Brasil no Debian GNU/Linux seguindo as instruções em artigo anterior aqui no blog, agora esbarra na instalação do IRPF 2017. O programa instalador exige Oracle Java. A solução de contorno mais rápida está sendo instalar usando o JAR diretamente, seguindo o download da instalação para Solaris e outros. Uma pena que desta forma não irá criar os menus para você. Mas vai poder criar manualmente ou usar diretamente a partir da linha de comando. Primeiro siga os  links de download  do site da Receita Federal para  Computadores com Mac, Linux, Solaris . Aí escolha  Solaris / outros (JAR) . Irá abrir a  página de download e instruções  onde você clicará no "Programa IRPF 2017". A instalação será simples, feita na sua área de usuário sem privilégios. Confirme que tem java instalado: $java -version openjdk version "1.8.0_111" OpenJDK Runtime Environment (build 1.8.0_111-8u111-b14-2~bpo

Atualização 31 março 2017: o Banco do Brasil passará a  exigir  a instalação  do módulo de segurança proprietário Warsaw a partir de 01 de abril 2017, desabilitando o acesso via plugin Java. Veja instruções de  outro site  sobre como instalar no Debian. Atenção se tiver baixado para mais de um banco, pois usam o mesmo módulo Warsaw que contém um daemon e poderá haver conflitos. São instruções adaptadas a partir do  passo a passo  do Banco do Brasil e a  seção FAQ para Linux . Desde novembro de 2016, o Banco do Brasil exige para acessar seu home banking que os navegadores utilizem plugin Java 8 quando usando Linux. Então temos a limitação de navegadores que ainda suportem plugin Java NPAPI, e da versão de API Java. Vamos mostrar como acessar usando Firefox ESR e OpenJDK 8 empacotados para Debian oficialmente e faremos um backport do IcedTea-Web para termos o plugin empacotado corretamente no Debian. Obteremos o código fonte do pacote IcedTea-Web do repositório do Debian 9.x Stretch

At this fourth article on the antispam subject, we will go to another layer of defense. Configuring Postfix SMTP server to help in reducing spam have advantages and imposes some risks. Stopping spam at SMTP layer has the advantages of reducing server load, server network bandwidth comsumption, and better dealing with botnets of windows machines and open relay servers. At other side, a sysadmin could exhagerate in some restrictions and then loose some valid messages. Finding the right balance is the key. After some years, I found that SpamHaus URIBL and RBL are the more conservative and better lists to use at this SMTP layer. I never found a false positive. But you should not use the more aggressive ones. It is better to leave some spam slip through to be caught at SpamAssassin than to loose some valuable message. So, our suggestion is to  INCLUDE  the following smtp client restrictions arguments at /etc/postfix/main.cf configuration file. smtpd_client_restrictions

SpamAssassin effectiveness at non-english language spam may be less than desirable, and when you starting to use bayesian rules, you do not have enough spam and ham specimens for training. Also, you can understand SpamAssassin as a multilayer protection, and you could configure each level for improving results. At the side of spammers, you can think as sequential spam waves attacks, each during minutes to hours. Your e-mail address may be listed for attack on a given spam wave attack. The first spam wave attack is the worst because the messages are still unkown to submission RBL  URIBL, spamtraps and rules, and your e-mail addresses may be scheduled to be on it at the very first minutes. Each layer protection could start dealing with spam at a given wave onwards. Each layer increments protection effectiveness and accuracy, but each one is more and more delayed in deployment and less accurate, broadly speaking. You have bayesian filters, submission RBL and URIBL, then RBL URIBL and WL,

One can  improve  the default effectiveness and accuracy of SpamAssassin on Debian systems by automatically updating its rules from official channel and from suggested channel. This tutorial will show how to update the rules and include the  Sought  automatically generated daily rules from messages caught in spam traps. Also, read the other " Related Content " articles at this site regarding antispam and SpamAssassin linked. vi /etc/default/spamassassin # Cronjob # Set to anything but 0 to enable the cron job to automatically update # spamassassin's rules on a nightly basis #AFM 20150723  https://wiki.apache.org/spamassassin/ImproveAccuracy CRON=1 mkdir ~/spamassassin cd ~/spamassassin/ mkdir /etc/spamassassin/sa-update-keys chmod go-rx /etc/spamassassin/sa-update-keys mkdir -p ~/temp/etc cd ~/temp/etc cp -pr /etc/spamassassin . ls -lh /var/lib/spamassassin/ ls -lh /var/lib/spamassassin/sa-update-keys/ ls -lh /var/lib/spamassassin/3.004000/ ls -lh /va

SpamAssassin can automatically mantain a MEAN  score  of e-mail addresses based on  ham  or  spam  received. You can read more on  https://wiki.apache.org/spamassassin/AutoWhitelist It is NOT a manual whitelist   https://wiki.apache.org/spamassassin/ManualWhitelist  . It MUST NOT be the only filter you will use. And CAN score in the wrong way  https://wiki.apache.org/spamassassin/AwlWrongWay It stores a pair  e-mail address and source IP , so spammers could only blacklist your own address after invading / exploiting your server. In these cases you MUST take forensic measures to analyze your server and stop the exploiting / invasion.  Also you should manually whitelist your own addresses or edit the auto whitelist database using appropriate tools. Then after cleaning, your server likely being on blacklists, you should ask for removal on those blacklists. The awl database is a perl hash in gdbm format and must be created and edited by tools. https://packages.debian.org/sta

= Objetivo = Estudo sobre storage defined storage focado em cenário de servidor de arquivos, especificamente o OwnCloud, em escala governamental. Existia uma implantação sobre máquinas físicas rodando RHEL e gravando em GFS2 mas que não atingia resultados satisfatórios nem em desempenho nem estabilidade e disponibilidade. Um estudo emergencial para uma nova proposta rodando sobre máquinas virtuais Debian que deveria satisfazer requisitos de dobro de desempenho foi realizado  ainda para alcançar estabilidade e disponibilidade de serviço com menores recursos. == Perfil de uso == Um servidor de arquivos , e especificamente o OwnCloud, deverá ter o perfil de escritas e leituras assíncronas aleatórias paralelas simultâneas de arquivos médios. Usaremos o perfil obtido segundo bibliografia: Web File Server, 64KB, 95% RD vs. 5% WR, 75% RAND vs. 25% SEQ, 0,02 IOPS/active_user avg, 0,8 IOPS/active_user peak. Teremos de modelar da melhor forma possível a distribuição de quantid