É um avançado sistema operacioal baseado na versão Unix BSD, desenvolvido pela Universidade de Barkeley. Robusto e estável, ele fornece um controle avançado dos parâmetros de desempenho, segurança e conectividade TCP/IP, alem de compatibilidade com o Linux e outros sistemas operacionais. Possui uma estrutura confiavel e robusta para comportar grandes cargas de acesso com milhares de conexões simultaneas. Dentre varias caracteristicas podemos citar:

• É multitarefa preemptiva ( multiplas CPU’s ), aliada ao ajuste dinâmico de prioridades e algoritimos para a proteção de memória;
• É indicado para aplicações de grande capacidade de I/O ( Input/Output ) de disco devido ao seu sistema nativo de arquivos e metodologias de acesso a disco;
• Atualização constante pelo Soft Update para sistema de arquivos Unix File System;
• Kernel suporta Ipv6, SMP, criptografia GBDE ( GEOM Based Disk Encryption )  ou GELI, firewalls stateful e jail aplicado a tecnicas de virtualização de sistema operacional;
• Controla acesso ao disco, por quotas de usuario ou para auditoria de eventos com CAPP ( Controlled Access Protection Profile ) e ACL ( Access List );
• Possui filtro de pacotes PF ( Packet Filter ) para controlar largura de banda e priorização de pacotes;
• IPSec ( IP Security ) para criptografar as conexões entre equipamentos com recursos nativos do Kernel;
• Executa de forma eficiente binarios pertencentes a outros sistemas operacionais;
• Concentra um record de 2 Terabytes de armazenamento de um unico sistema operacional;
• Pode ser utilizado para a construção de qualquer tipo de servidor.

So para finalizar, ele é utilizado por empresas como Yahoo! ( http://www.yahoo.com/), Apache ( http://www.apache.org/ ), Sony ( http://www.sony.co.jp/), dentre outras que confiam suas aplicações a esse sistema, que na minha opnião é o melhor quando se tratando de Servidores.

Vale ressaltar que o melhor sistema operacional é aquele que atende as necessidades do usuario, mas so para confrontá-lo com os outros sistemas operacionais, vale ressaltar alguns pontos entre o FreeBSD e os dois mais utilizados no segmento de servidores.

FreeBSD x Windows

• Alto custo para implementação devido ao preço de suas licenças.
• O hardware deve ser muito robusto para melhorar seu desempenho, um exemplo do maior fracasso da microsoft nesse quesito,  foi o Windows Vista .
• O kernel do windows nao é personalizavel. Sendo impossivel adcionar ou remover recursos para torna-lo mais rapido, simples e seguro.
• Usam interface grafica para realização de tarefas. Exceto o Windows 2008 Server Core.
• Possui uma grande variedade de profissionais, desvalorizando o salario dos mesmos. Ao contrario, para se encontrar profissionais que dominem realmente um sistema Unix como Linux e FreeBSD com qualidade é mais dificil.

FreeBSD x Linux

• São derivados do Unix, porem o linux possui diversas distribuições enquanto o FreeBSD apenas uma. Sistemas linux, mantem varias equipes de diferentes distribuições, desenvolvendo em paralelo varias aplicações e adaptações.
• O kernel do linux é mantido pelas ideias de seu criador Linus Torvald, enquanto o FreeBSD possui apenas uma equipe que simplifica a manutenção e gerenciamento.
• As licenças do Linux não permite que seu codigo fonte seja apoderado ou que seja aplicado restrições quanto a sua distribuição, enquanto a do FreeBSD são mais permissivas e facilitam o uso de produtos comerciais.
• O FreeBSD consegue executar 90% dos aplicativos linux sem nenhum ajuste ou adaptação no sistema, e possui um grande controle de I/O em disco com melhor qualidade do que qualquer distribuição linux.

Para obter uma distribuição do FreeBSD basta entrar no site http://www.freebsd.org/ e baixar plataforma compativel com seu hardware.

Caso tenha em mãos a arquitetura do seu hardware, basta instalar. Não é dificil, pelo contrario, é bem simples e facil. Porem se tratando de servidores que irão disponibilizar grandes aplicações, é recomendado que faça antes de tudo um Check-list de pré-instalação. Sintetizando, basta especificar :

• Nome da maquina. Defina padrões para nomes em redes, isso facilita a administração. Porem não dê nomes descritivos sobre a função do equipamento, como dns, web-server, storage, base-de-dados, etc.
• Defina seu hardware. Verifique sua compatibilidade e descreva cada componente minuciosamente para evitar problemas.
• Escolha o metodo de instalação ( CD/CDROM).
• Faça um modelo de backup de dados. Defina local, tempo e restrições.
• Identifique o equipamento de conexão de rede utilizado e o mapeamento da mesma.
• Defina equipamentos de storage, suas partições, endereços e se será utilizado equipamentos de redundância RAIDS e etc.
• Defina configurações de firewall, nome do dominio, dns, gateway, ips e etc.
• Climatização, segurança, prevenindo incendios, explosões e etc.

Enfim, um check-list, pode ser simples ou complexo, depende da necessidade de qualidade da sua implementação. Existem normas padrões para isso, basta pesquisar sobre ISO/IEC e normas para gerenciamento de TI.

Agora basta colocar a “mão na massa”!!!

Submitted a PR for solang on FreeBSD.

Many options can be added to your shell prompt such as :

• Server name,
• Date and time,
• Current folder,
• Current user name.

The file where you have to customize your prompt options depends on what shell are you using or for which shell do you want to customize the prompt.

For the moment, I will start by the csh and tcsh and I will add for others shells next time.

The csh shell

Open the .cshrc file and after the line “# An interactive shell — set some stuff up” specify the options for your prompt

set prompt =”%n@%m%/%# “

The Tcsh shell

You have to modify the .tcshrc file. If you don’t have it you can create one by copying the same content of the .cshrc file:

$cp .cshrc .tcshrc

Then you can modify the options of your prompt if the set prompt line is already available or add a new your options after the line “# An interactive shell — set some stuff up”:

set prompt =”%m[%t]%/%# “

Display user’s information on FreeBSD:

$pw showuser username

Replace username with the username account

Change the user’s shell:

$pw usermod username -s /bin/tcsh

Replace the username with the username account. You can choose one of the shells available in your system.

Many shells are available for use in Unix based systems.

• sh: available on all Unix systems. It is an old shell.
• ksh: based on sh and gives additional futures.
• csh: not based on sh. available on all Unix systems
• tcsh: based on csh with additional futures.

Display available shells in your system

$cat /etc/shells

IPFW:check-state/keep-state advanced stateful rules.  By Joe Barbish  07/22/2002  All rights reserved.
As most new ipfw users, I had a typical ipfw rules file built from the simple stateful rules in rc.firewall. I had originally been using user ppp with it’s internal Nat function, but went to natd as the simple stateful type in rc.firewall showed. Since the sample rc.firewall (simple) was pretty much just what I wanted to do, I just assumed this was the correct and proper way, so I cut out the simple type code from rc.firewall to create my own ipfw firewall rules. In searching FBSD and the many sites found by google search I saw many many other people before me had done the same thing. From a technical point of view the whole rc.firewall file is based on simple stateful rules using setup/established with some stateless rules thrown in. As a new ipfw user I did not know the difference and the comments sure did not call out the difference.
When I tried to change my simple stateful [established/setup] to advanced stateful [check-state/keep-state] rules, I kept having trouble with ip address being mismatched. Technically the mismatches showed up in /var/log/security as packets that got denied by the (default deny everything rule) for all packets that reach the end of the rule set with out matching any rule. Configuration looked like this.
Divert natd (network address translation)                   (                   (LAN PC’s  < — > IPFW  < — >  internetPrivate IP     advanced        public ip  Address      stateful rules    address
I spend weeks playing around trying different combinations of ipfw rules, but kept having mismatches in the dynamic table. Finally I removed the natd divert rule from the ipfw rules set and deactivated natd in rc.conf and re-activated ppp -Nat in rc.conf, and the advanced stateful [check-state/keep-state] rules started to work. Configuration looked like this.

LAN PC’s  < — > IPFW  < — >  user ppp -nat < — > internetPrivate IP     advanced        network address      public ip  Address      stateful rules    translation           address
In this configuration IPFW only knows the private ip address on the LAN and the advanced stateful rules functioned just like described in the man documentation.
I wrote emails to the IPFW authors, gave then 2 documented examples of rules sets using exclusively advanced stateful rules and user ppp dial up ISP, the only difference was one used user ppp -nat and did not have the divert natd rulecd ../ one had the divert natd rule and no user ppp -nat and did not work. After much conflicting correspondences the results were that they were not going to do anything about it and I was left on my own.
The real problem here is ipfw advanced stateful rules are relatively new to the IPFW program (FBSD version 4.0 year 2000) and still does not fit cleanly into the divert natd program logic.
IPFW was originally designed as a firewall using stateless rules and/or simple stateful rules which is nothing more than an rules file coding logic technique based on the TP flags setup/established. Using these very primitive type of rules IPFW function’s correctly. When advanced stateful rules are used to tighten down the control of packets passing through the firewall by dynamically creating an internal rules table based on the by-directional exchange of packets which have to match the pre-known ip address, flow direction, and packet sequence numbers the divert natd function malfunctions. This problem is not limited to dial up internet access, but also occurs for ‘all ways on’ environments (DSL, Cable, T1) with or without DHCP support.
Many users reach this point using the advanced check-state/keep-state stateful rules and go back to simple stateful rule set using established/setup simple because they can not get the advanced stateful rules to work. The rc.firewall file was created for FBSD 2.0 and has not been updated to exclusively utilize the advanced stateful rule set, so it is a very poor example to be using for your ipfw rules set.
Cable internet access became available in my area and I was forced to revisit the divert natd / advanced stateful rules again because (DSL, Cable, T1) ‘all ways on’ environments normally use the ISP’s DHCP server to get it’s network configuration information so user ppp -nat is not used in this case. This meant I had to use the divert natd ipfw statement to provide the NAT function so I could use private ip address for my LAN because my cable ISP only issues one dynamic public ip address per customer account.
After many days of trial and error testing I finally found an rules coding logic which functioned correctly using exclusively advanced check-state/keep-state stateful rules and the divert natd rule statement. Normally the rule to allow the packets from local LAN Nic cards to pass through the ipfw firewall come before the divert natd rule as seen in the rc.firewall file. But for advanced stateful rules it has to be moved after the divert natd rule and the ‘keep-state’ option has to be used so the dynamic rules table knows about the packet activity before they get passed through the rules file the second time. Technically this means each packet will have 2 sets of dynamic table rules, one set for the private Nic interface and one for the public Nic interface. This is an resource waste, decreases performance, and not necessary if the nat function is done outside of ipfw.
The simplest and best solution to the advanced stateful rules problem is to use ‘user ppp -nat’ for all dialup ISP environments and have no divert natd rule in the ipfw rules file.  For all DSL, cable, and T1 connection where the ISP’s DHCP is used to configure FBSD’s public network you have to use the divert natd rule in your ipfw rules set followed by this rule for each private Nic interface,  ’allow all from any to any via xl0 keep-state’
where xl0 is the private Nic card interface device name. This solution has been tested in FBSD version 4.5 & 4.6.
The IPFW rules listed below are my current firewall rules file configured for a cable divert natd environment. Here are the matching /etc/rc.conf optionsifconfig_rl0=”DHCP”ppp_enable=”NO”             natd_enable=”YES”natd_interface=”rl0″natd_flags=”-dynamic”firewall_enable=”YES”                 firewall_script=”/etc/ipfw.rules.conf”

For an user ppp dialup modem ISP connection using ‘divert natd’ make following changes to the ipfw rules below   Change  oif=”rl0″  to  oif=”tun0″
Here are the matching /etc/rc.conf options#ifconfig_rl0=”DHCP”ppp_enable=”YES”ppp_mode=”ddial”             ppp_profile=”papchat”        ppp_nat=”NO”                       natd_enable=”YES”natd_interface=”tun0″natd_flags=”-dynamic”firewall_enable=”YES”                 firewall_script=”/etc/ipfw.rules.conf

For an user ppp dialup modem ISP connection using ‘user ppp -nat’ make following changes to the ipfw rules belowChange  oif=”rl0″  to  oif=”tun0″  Add    $cmd 00130 allow all from any to any via xl0Delete $cmd 00150 divert natd all from any to any via $oifDelete $cmd 00210 allow all from any to any via xl0 keep-state
Here are the matching /etc/rc.conf options#ifconfig_rl0=”DHCP”ppp_enable=”YES”ppp_mode=”ddial”             ppp_profile=”papchat”        ppp_nat=”YES”                       natd_enable=”NO”#natd_interface=”tun0″#natd_flags=”-dynamic”firewall_enable=”YES”                 firewall_script=”/etc/ipfw.rules.conf

Following the rules file below are some other IP stack security options which are specified in the /etc/rc.conf file and kernel that you can use as a guide to configure your own world.
/etc/ipfw.rules.conf############################################################################# Define IPFW firewall rules for gateway.poweruser.net # 7/04/2002  Joe Barbish  ##   Cable modem connection to ISP with dynamic IP addresses assigned.#   Private Ip address used inside.#   3 win98 boxes on LAN with DHCP used for auto private network configure. #   Protect the whole private network from loss of service attacks#   These rules can be reloaded with out rebooting by issuing this command#   sh /etc/ipfw.rules.conf##   The use of ‘me’ in rules means IP address 127.0.0.0 localhost #   # Firewall Policy Statement.#   Each public internet function must be explicitly allowed by a rule.#   Only valid response to the packets I’ve sent out are allowed in.#   All packets must use the IPFW advanced “dynamic” rules function.#   No state-less rules or simple-stateful rules are allowed to grant#   internet function.#############################################################################
# Flush out the list before we begin./sbin/ipfw -q -f flush
# Set rules command prefix# The -q option on the command is for quite mode. # Do not display rules as they load. Remove during development to see.cmd=”/sbin/ipfw -q add”
# Set defaults  # set your outside interface network device name and # domain name servers IP address to values issued by your ISP.

oif=”rl0″                  # Nic card to cable modem public internet connectionodns1=”24.50.201.66″       # ISP’s dns server 1 IP addressodns2=”24.52.201.66″       # ISP’s dns server 2 IP address
# Set these to your inside interface network and ip address rangeiif=”xl0″                  # Nic card to private internal Local area network

# This is the start of the rules. # All traffic coming in from the internet or# leaving the local LAN start here

# Internal gateway housekeeping# Rules # 100 exempt everything on localhost behind the firewall from this rules set.# Rules # 110 & 120 deny the reference to the localhost default IP address.$cmd 00100 allow all from any to any via lo0  # allow all localhost$cmd 00110 deny log  all from any to 127.0.0.0/8  # deny use of localhost IP $cmd 00120 deny log  all from 127.0.0.0/8 to any  # deny use of localhost IP

# This does the  Network Address translation of every packet coming in# or going out over the public internet.
$cmd 00150 divert natd all from any to any via $oif
#*** TESTING PURPOSES ONLY *** TESTING PURPOSES ONLY *** TESTING PURPOSES ONLY# The following rule if un-commented will change the behavior of this# Firewall rule set from closed to completely open, thus bypassing all of the# following rules. This single rule is placed here for TESTING PURPOSES ONLY.#$cmd 00160 allow log logamount 500 all from any to any#$cmd 00161 allow all from any to any

########  control section  ############################################# Start of IPFW advanced Stateful Filtering using “dynamic” rules.# The check-state statement behavior is to match bi-directional packet traffic# flow between source and destination using protocol/IP/port/sequence number. # The dynamic rule has a limited lifetime which is controlled by a set of# sysctl(8) variables. The lifetime is refreshed every time a matching# packet is found in the dynamic table.
# Allow the packet through if it has previous been added to the # the “dynamic” rules table by an allow keep-state statement. $cmd 00200 check-state
# Run all private Lan packet traffic through the dynamic rules# table so the IP address are in sync with Natd.$cmd 00210 allow all from any to any via xl0 keep-state
# Deny all fragments as bogus packets $cmd 00250 deny all from any to any frag in via $oif
# Deny  ACK packets that did not match the dynamic rule table$cmd 00260 deny tcp from any to any established in via $oif

########  outbound section  ############################################# Interrogate packets originating from behind the firewall, private net.# Upon a rule match, it’s keep-state option will create a dynamic rule.
# Allow out non-secure standard www function$cmd 00300 allow tcp  from any to any 80  out via $oif setup keep-state
# Allow out secure www function https over TLS SSL$cmd 00301 allow tcp  from any to any 443 out via $oif setup keep-state
# Allow out access to my ISP’s Domain name server. $cmd 00310 allow tcp  from any to $odns1 53 out via $oif setup keep-state $cmd 00311 allow udp  from any to $odns1 53 out via $oif keep-state$cmd 00315 allow tcp  from any to $odns2 53 out via $oif setup keep-state  $cmd 00316 allow udp  from any to $odns2 53 out via $oif keep-state
# Allow out send & get email function$cmd 00330 allow tcp from any to any 25  out via $oif setup keep-state$cmd 00331 allow tcp from any to any 110 out via $oif setup keep-state
# Allow out & in FBSD (make install & CVSUP)  functions# Basically give user id root  ”GOD”  privileges.$cmd 00340 allow tcp from me to any out via $oif setup keep-state uid root
# Allow out & in console traceroot command$cmd 00342 allow udp from me to any 33435-33500 out via $oif keep-state  $cmd 00343 allow log icmp from any to me icmptype 3,11 in via $oif limit src-addr 2
# Allow out ping $cmd 00350 allow icmp from any to any   out via $oif keep-state
############ passive FTP rules to public Internet ####### Allow passive FTP control channel 21 & data high ports $cmd 00375 allow tcp  from me to any 21  out via $oif setup keep-state$cmd 00376 allow tcp  from me to any 10000-65000  out via $oif setup keep-state############ End of passive FTP rules to public Internet ######
# Allow out ssh $cmd 00380 allow tcp  from any to any 22   out via $oif setup keep-state
# Allow out TELNET $cmd 00390 allow tcp  from any to any 23    out via $oif setup keep-state
# Allow out Network Time Protocol (NTP) queries #$cmd 00394 allow tcp  from any to any 123   out via $oif setup keep-state#$cmd 00395 allow udp  from any to any 123   out via $oif keep-state
# Allow out Time $cmd 00396 allow tcp  from any to any 37    out via $oif setup keep-state$cmd 00397 allow udp  from any to any 37    out via $oif keep-state
# Allow out ident#$cmd 00400 allow tcp  from any to any 113   out via $oif setup keep-state#$cmd 00401 allow udp  from any to any 113   out via $oif keep-state
# Allow out IRC#$cmd 00410 allow tcp  from any to any 194   out via $oif setup keep-state#$cmd 00411 allow udp  from any to any 194   out via $oif keep-state
# Allow out whois$cmd 00412 allow tcp  from any to any 43    out via $oif setup keep-state$cmd 00413 allow udp  from any to any 43    out via $oif keep-state
# Allow out whois++#$cmd 00415 allow tcp  from any to any 63    out via $oif setup keep-state#$cmd 00416 allow udp  from any to any 63    out via $oif keep-state
# Allow out finger#$cmd 00420 allow tcp  from any to any 79    out via $oif setup keep-state#$cmd 00421 allow udp  from any to any 79    out via $oif keep-state
# Allow out nntp news$cmd 00425 allow tcp  from any to any 119   out via $oif setup keep-state$cmd 00426 allow udp  from any to any 119   out via $oif keep-state
# Allow out gopher#$cmd 00430 allow tcp  from any to any 70    out via $oif setup keep-state#$cmd 00431 allow udp  from any to any 70    out via $oif keep-state

########  inbound section  ############################################# Interrogate packets originating from in front of the firewall, public net.# Place statements here to allow public requests for service.
# Allow in www$cmd 00600 allow tcp from any to any 80 in via $oif setup keep-state limit src-addr 4
# Allow  TCP FTP control channel in & data channel out $cmd 00610 allow tcp from any to me 21  in via $oif setup keep-state limit src-addr 4$cmd 00611 allow tcp from any 20 to any 1024-49151 out via $oif setup keep limit src-addr 4
# Allow in ssh function $cmd 00620 allow log tcp from any to me 22 in via $oif setup keep-state limit src-addr 4
# Allow in Telnet  $cmd 00630 allow tcp from any to me 23 in via $oif setup keep-state limit src-addr 4
# Allow in Ping $cmd 00635 allow log icmp from any to me icmptype 0,8  in via $oif
# This sends a RESET to all ident packets.#$cmd 00640 reset log tcp from any to me 113  in via $oif limit src-addr 4
########  Catch all section  ############################################
#### Start Special rules for Adelphia Cable  #########################
#valid dhcp broadcast from Adelphia dhcp server$cmd 00700 allow UDP from 0.0.0.0 68 to 255.255.255.255 67 in via rl0
# valid FBSD dhcp client request for dns config info$cmd 00701 allow udp from me 68 to $odns1 67      out via rl0$cmd 00702 allow udp from $odns1 67 to me 68       in via rl0
# invalid bogus packets on Adelphia Cable network.$cmd 00705 deny udp from any to 255.255.255.255    in via rl0$cmd 00706 deny udp from 0.0.0.0 to any            in via rl0#               P:2$cmd 00707 deny all  from 192.168.100.1 to 224.0.0.1   in via rl0$cmd 00708 deny udp from $odns1 53 to me           in via rl0#### End Special rules for Adelphia Cable  #########################

# Stop & log external redirect requests.$cmd 00720 deny log icmp from any to any icmptype 5  in via $oif
# Stop & log spoofing Attack attempts.# Examine incoming traffic for packets with both a source and destination# IP address in my local domain as per CIAC prevention alert.$cmd 00730 deny log ip from me to me  in via $oif
# Stop & log ping echo attacks# stop echo reply (ICMP type 0), and echo request (type 8).$cmd 00740 deny log icmp from any to me icmptype 0,8  in via $oif
# Reject & Log all setup of tcp incoming connections from the outside$cmd 00750 deny log tcp from any to any  setup  in via $oif
# Reject & Log all netbios service. 137=name, 138=datagram, 139=session# netbios is ms/windows sharing services.$cmd 00760 deny log tcp from any to any 137,138,139  in via $oif$cmd 00761 deny log udp from any to any 137,138,139  in via $oif
# Reject all port 80 http packets that fall through to here.# These packets are auto spawn web page requests from within # original web page request.$cmd 00770 deny  tcp from any to any 80   out via $oif
# Everything else is denied by default # deny and log all packets that fell through to see what they are$cmd 00950 deny log logamount 500 all from any to any
################## End Of IPFW Firewall Rules  #########################

Other IP stack security options.The main run control configuration file /etc/rc.conf has a whole group of run time security options to control the flood of falsified packets entering the system which get control before IPFW evens knows their coming in.
The following is from my rc.conf file.
# Required IPFW  kernel firewall support# For more info see # www.onlamp.com/pub/a/bsd/2001/04/25/FreeBSD_Basics.html #
firewall_enable=”YES”                 # Start daemonfirewall_script=”/etc/ipfw.stdrules”  # run my custom rules if present                                      # sh /etc/ipfw.stdrules will load                                       # new rules file after editing.filewall_logging=”YES”                # Enable events logging

# Extra firewalling optionslog_in_vain=”YES”           # NO is default. YES enables logging of                             # connection attempts to ports that have no                            # listening socket on them. Put msg on consol
icmp_drop_redirect=”YES”    # YES will cause the kernel to ignore                            # ICMP REDIRECT packets.
tcp_drop_synfin=”YES”       # YES will cause the kernel to ignore TCP                            # frames that have both the SYN and FIN flags                            # set. Only available if the kernel was built                            # with the TCP_DROP_SYNFIN option.                            # change to NO if web server behind firewall.
tcp_restrict_rst=”YES”      # YES will cause the kernel to refrain from                             # emitting TCP RST frames in response to                             # invalid TCP packets (e.g., frames destined                            # for closed ports). This option is only                             # available if the kernel was built with the                            # TCP_RESTRICT_RST option.
syslogd_flags=”-ss”         # Don’t use network sockets so portscan          # will not find (security tip)
portmap_enable=”NO”         # Don’t allow nfs portmapper (security tip)

The  log_in_vain=”YES” option will post a message to the root console screen every time it stops a packet. This became very annoying so I changed the syslog to put these messages in the security log. All the ipfw messages that were going to the /var/log/security file was also going to the /var/log/message file. I did not think it was wise to be posting ipfw messages in more that one place, so I stopped them from going to the message file.  Below are the lines I changed in /etc/syslog.conf to make this happen.

The original lines.*.err;kern.debug;auth.notice;mail.crit /dev/console*.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messagessecurity.* /var/log/security
replaced by this lines# kern.info is where the log_in_vain messages come from. The following# will stop the log_in_vain messages from coming out on root console &# put them in the security log.  2/20/2002 Joe Barbish# remove kern.info messages from /dev/console & /var/log/messages# and put them into /var/log/security.*.err;auth.notice;mail.crit /dev/consolekern.notice;kern.=debug /dev/console*.notice;lpr.info;mail.crit;news.err /var/log/messageskern.notice;kern.=debug /var/log/messagessecurity.*;kern.=info /var/log/security

Another very obscure option is blackhole, new in FBSD 4.4
The blackhole sysctl(8) is used to control system behavior when connection requests are received on TCP or UDP ports where there is no socket listening.
Normal behavior, when a TCP SYN segment is received on a port where there is no socket accepting connections, is for the system to return a RST segment, and drop the connection. The connecting system will see this as a “Connection reset by peer”.
By setting the TCP blackhole MIB to a numeric value of 1, the incoming SYN segment is merely dropped, and no RST is sent, making the system appear as a blackhole.
By setting the MIB value to 2, any segment arriving on a closed port is dropped without returning a RST.  This provides some degree of protection against stealth port scans.
In the UDP instance, enabling blackhole behavior turns off the sending of an ICMP port unreachable message in response to a UDP datagram which arrives on a port where there is no socket listening. It must be noted that this behavior will prevent remote systems from running traceroute(8) to a system.
The blackhole behavior is useful to slow down anyone who is port scanning a system, attempting to detect vulnerable services on a system. It could potentially also slow down someone who is attempting a denial of service attack.
The sysctl net.inet.tcp.blackhole=2 command can be entered from the command line and will be in effect until the next boot. The sysctl command can also be in the /etc/sysctl.conf file (which you must create) and if present will be activated during the boot process. Read man sysctl for command format to display settings of this option and some others that allow you to change to default dynamic rules time out values. For the really advanced technical ipfw user check out ipfw user patches at  http://people.freebsd.org/~cjc/
See http://bsdvault.net/sections.php?op=viewarticle&artid=57 for info on sysctl.
See http://www.practicallynetworked.com/sharing/app_port_list.htm  for a list of ports used by different applications.
/etc/sysctl.conf  file contents
sysctl net.inet.tcp.blackhole=2sysctl net.inet.udp.blackhole=1

Here are the statements for the kernel source to include IPFW in the kernel.## The following options add sysctl variables for controlling how certain # TCP packets are handled by the kernel. #options        ICMP_BANDLIM        # Enables icmp error response bandwidth                                      # limiting. This will help protect from                                       # D.O.S. packet attacks.option          TCP_DROP_SYNFIN       # Adds support for ignoring TCP packets                                       # with SYN+FIN. This prevents nmap from                                       # identifying the TCP/IP stack, but                                       # breaks support for RFC1644 extensions                                      # & is not recommended for web servers.
# not supported in 4.4 & newer#option          TCP_RESTRICT_RST     # Adds support for blocking emission of                                      # TCP RST packets. Useful in limiting                                       # SYN floods & port scanning.

# Enable kernel IPFW, the FBSD supplied packet filtering and accounting system# Has a FBSD supplied user land control utility ipfw.# option IPFIREWALL                  # Adds filtering code into kerneloption IPFIREWALL_VERBOSE          # enable logging thru syslogd(8)option IPFIREWALL_VERBOSE_LIMIT=10 # stop attack via syslog floodingoption         IPFIREWALL_IPDIVERT         # Enable NATD divert function

Otro avance en el port BSD para Debian, ahora es posible instalar el metapaquete GNOME para esta distribución, ahora se puede ofrecer un escritorio completo para esta versión, esto aplica para las versiones amd64 e i386, aunque claro esto con algunas excepciones:

-No hay soporte para manejo de energia (DeviceKit-Power necesita ser portado)
-No hay soporte para wireless (libiw necesita ser portado)
-No hay soporte para Bluetooth (el kernel FreeBSD no tiene soporte)
-No hay soporte para webcams.

Dejando eso a un lado, todo lo demás trabaja como debería, aunque se necesitan personas que prueben este entorno de escritorio en la versión. Para ello nos invitan a descargar e instalar Debian GNU/kFreeBSD en una maquina virtual, actualizar a la ultima versión de Sid e instalar gnome apt-get install gnome

Este es otro paso para Debian 6, ya que recordemos que esta versión sera la primera en ofrecer un soporte al kernel FreeBSD, que aunque ya esta, sera una alternativa mas al kernel Linux.

Visto en | Joss Blog

說穿了其實也沒多困難，看一下 mdconfig 的 manual 就差不多可以上手了。這次要測試碰巧是因為想要試試看是不是真的如過去經驗一樣，compile 的速度瓶頸卡在 disk I/O 比較大，所以決定做個 memory disk 來放 /usr/obj。

做法就參考 manual 還有 in2 加持過的建議：

mdconfig -a -t malloc -o reserve -s 2g -u 0
newfs -U /dev/md0
mount /dev/md0 /usr/obj

然後咧？當然又是來一次 make -j64 buildworld 啦！結果當然是快了一些，只花了 22min 左右就結束了 XD

PS. 因為上次把機器玩爛了，昨天重灌一次，用的是 8.0-RELEASE (沒錯，已經偷偷上線了 )

FreeBSD – это современная операционная система для компьютеров, совместимых с архитектурами x86 (в том числе Pentium® и Athlon™), amd64 (включая Opteron™, Athlon 64 и EM64T), Alpha/AXP, IA-64, PC-98 и UltraSPARC®. Она основана на BSD, версии UNIX®, созданной в Калифорнийском Университете в Беркли.

Официальный сайт: www.freebsd.org
Скачать: FreeBSD 8.0 Final

因為工作的關係，昨天在公司的一台 IBM x3850 M2 上面安裝 FreeBSD，一共試了兩個版本 (6.4 & 8.0-RC3)，都是 amd64 的。6.4 的光碟放進去跑到 loader 就當住不動了，8.0-RC3 的就很順利地裝完，並且正常使用 (直到我自己亂搞的 kernel 把機器弄到開不起來為止)。

硬體的部分應該都有抓到而且可以正常使用，包括 Xeon E7320*2 (可以一共看到 8 顆 CPU)、8G 的 RAM、還有 ServeRAID-MR10k 上面接的 73G 10k SAS HDD (mfi)、兩個 Broadcom GbE 網路 (bce)。裝完之後有徵求過鄉民的意見，跑了一次 make -j64 buildworld，大概花了 25 分鐘。之後就因為我自己編的 kernel 有問題，重開之後掛在路上，等著我星期一進公司再處理 :Q

值得一提的是，mfi 的 driver 還會提醒我 RAID card 電池的狀態，公司這台機器的 RAID card BBU 似乎有點問題，常常顯示電池需要更換或是充電中的訊息。

Há uma certa tendência de muitos acreditarem que não existem vírus para sistemas operacionais abertos, como o GNU/Linux. Isso não é uma verdade absoluta. Na verdade, existem cerca de 1000 vírus conhecidos vírus para GNU/Linux (contra cerca de 6 milhões – e subindo – deles para os sistemas janelas), incluídos aí os rootkits, worms e scripts para invasão.

E isso é motivo para alarmes? Na verdade, não. Uma questão relevante sobre a existência de malwares é o impacto que tais programas têm no sistema infectado. Os vírus são desenvolvidos para explorar falhas de segurança dos sistemas. Descobrir falhas de segurança em sistemas proprietários é um pouco mais difícil do que em sistemas abertos, porque, no primeiro, o cracker precisa fazer uma engenharia reversa para “recuperar” o código fonte. No segundo, o código fonte está disponível para qualquer pessoa.

Auditoria de código.

O que parece uma desvantagem para o sistema aberto, na verdade, é uma absurda vantagem. Enquanto que, nos sistemas fechados, o cracker faz a engenharia reversa, ou outros métodos, descobre as falhas e cria maneiras de explorá-las para, somente depois, o vírus ser descoberto pelos pesquisadores e empresas de segurança, e medidas sejam tomadas para, primeiro, contornar (antivírus), e depois corrigir a falha (correções e atualizações), nos sistemas abertos, o código é auditado constantemente por milhares de desenvolvedores voluntários ao redor do mundo. Isso permite que as falhas sejam descobertas e corrigidas com mais rapidez. O mesmo trabalho que um cracker teria de fazer para descobri-las, já é feito diariamente por muitas pessoas. Além de descobrir um código defeituoso, ele teria de procurar se esse defeito já não está documentado, pois se estiver, a correção estará na próxima atualização, com certeza. Nos sistemas fechados, a velocidade de pesquisa dos códigos e de correção é absurdamente maior, o que significa que, mesmo que a falha seja descoberta, não significa que será corrigida imediatamente. Isso expõe o sistema a ataques que a explorem.

Isso também significa que, nos sistemas abertos, os crackers estão no mesmo passo dos desenvolvedores, ou um passo atrás, mas estão sempre um ou dois passos à frente nos sistemas proprietários.

Atualizações e correções.

As atualizações de segurança em sistemas abertos é feita da mesma forma que em sistemas fechados, ou seja, através do download de correções, ou de versões novas do software com defeito. Ocorre que, nos sistemas proprietários, temos uma fragmentação das fontes de software, ou seja, são vários fornecedores diferentes, trabalhando de maneira independente, nem sempre coordenada e, por vezes, concorrentes. Isso causa problemas do tipo ocorrido recentemente, em que uma correção de segurança do Internet Explorer, lançada pela M$, abriu brechas de segurança no Navegador Mozilla Firefox para janelas. Além disso, as correções são feitas independentemente, ou seja, cada um é responsável pelo seu pedaço: o antivírus, o sistema operacional, o pacote de escritório, o navegador, o cliente de email, o pacote gráfico, os jogos, o firewall, etc.

Nos sistemas abertos, isso é bastante minimizado, já que todas as atualizações são disponibilizadas nos repositórios oficiais. Também são automáticas, mas estão todas agrupadas e podem ser feitas de uma vez. Há coordenação entre as equipes de desenvolvimento através do responsável pela distribuição. Programas “não oficiais” podem ser instalados e ter sua atualização feita em separado, mas são poucos os casos, já que cada distribuição já inclui tudo, ou quase tudo, que é necessário para a maior parte das pessoas.

Exposição a ataques.

Há um mito que diz que apenas existem mais vírus para janelas porque o GNU/Linux é bem menos utilizado. Ou seja, o janelas é mais visado.

Isso é uma meia verdade. Se fosse possível comprovar essa afirmação, poderíamos supor seria proporcional a disponibilidade de malwares para os dois sistemas. Recentemente, foi publicada uma matéria sobre a taxa de penetração de cada um dos sistemas operacionais. O janelas (em todas as suas versões) ficou com aproximadamente 90%, O GNU/Linux com 1%, e o Sistema da Maçã com cerca de 5%. Seria, portanto, lógico supor que dos milhões de vírus conhecidos, a proporção fosse semelhante, mas não é o que acontece. Os vírus para GNU/Linux respondem por cerca de 0,16% do total de vírus conhecidos, número semelhante aos do Sistema da Maçã, sistema proprietário cujo desenvolvimento foi baseado em Unix.

Dos vírus conhecidos para Sistema da Maçã e GNU/Linux, não se comprovou que algum deles causasse transtornos semelhantes aos causados pelos que atingem o janelas. Além disso, a forma de considerar a segurança em sistemas Unix-like, como o GNU/Linux e o Sistema da Maçã, é completamente diferente e bem mais aprimorada. Numa instalação padrão, a exposição a ataques desses sistemas é consideravelmente menor. O que significa que se você pegar um CD e instalar uma distribuição qualquer do GNU/Linux em um computador conectado diretamente à Internet, a possibilidade de invasão é quase nula. O mesmo computador com uma instalação padrão do sistema janelas XP tem um tempo médio e resistência de 90 segundos. Ou seja, se você formatar a sua máquina e instalar o janelas XP nela, se ela estiver na Internet, você tem, em média, 90 segundos para instalar todas as atualizações de segurança, antivírus, antispyware, firewall, etc., o que é virtualmente impossível para qualquer “usuário comum”.

O janelas, ao contrário dos sistemas Unix-like, não foi originalmente concebido para trabalhar em rede. A demanda pela conectividade, na época do DOS+janelas 3.1, fez com que a M$ lançasse a versão 3.11 do janelas, com recursos de rede. A empresa tentou impor seu protocolo NetBeui como padrão para as redes locais, mas não conseguiu porque o TCP/IP já estava bem consolidado, e era utilizado na Internet restrita da época. Durante algum tempo, as redes locais não eram conectadas à Internet e trafegavam NetBeui. Quando começou a aparecer a necessidade de conectar essas redes à Internet, elas começaram a trafegar ambos os protocolos e, por fim, o NetBeui foi abandonado. As versões do janelas seguintes, não mudaram o conceito original. Hoje o janelas é altamente conectável, mas, como originalmente a segurança do sistema foi pensada para máquinas isoladas, quando muito conectadas em redes locais, por uma questão de compatibilidade com as versões anteriores e pelo custo de desenvolvimento, o conceito se propagou até os dias de hoje.

Custos de desenvolvimento e estratégia de marketing.

O custo de desenvolvimento de um sistema operacional completo pode chegar à casa de alguns bilhões de dólares. Por mais rica que uma empresa seja, um investimento desse tamanho é algo impraticável. Empresas como Petrobras, por exemplo, quando constroem uma refinaria de 2 ou 3 bilhões de dólares, invariavelmente procuram se associar a outras empresas e buscar financiamento de longo prazo em bancos, para o empreendimento. Vejam bem, uma refinaria pode ficar pronta em cerca de 2 ou 3 anos e tem um prazo de algumas dezenas de anos para pagar o financiamento e amortizar o investimento, além de dar lucro aos acionistas.

O que podemos dizer de um sistema operacional? Com a velocidade imposta para que uma versão de um sistema operacional proprietário seja substituído, seria necessário investir muitas centenas de milhões de dólares por ano no desenvolvimento de sistemas completamente novos para resolver o problema de segurança. Mas, a cada versão da família janelas, vemos as mesmas alegações de que o sistema novo é mais seguro que o antigo, fatos “comprovados” por pesquisas de cunho duvidoso e declarações de “especialistas” dos quais nunca se ouviu falar. O fato é que nunca se cria um sistema novo. Ela apenas se recicla códigos dos sistemas antigos, remodelando o velho para “criar o novo”, oferecendo um visual agradável para que o marketing atinja seus objetivos. É necessário que o ciclo seja curto para garantir os lucros altos. Portanto, não há tempo nem disponibilidade orçamentária, ou de financiamento, para a criação de um sistema novo, sem vícios herdados dos anteriores. Logo, o fato do janelas não ser um sistema seguro não se deve a uma questão de filosofia de código, mas a uma questão econômica. Se, mesmo com um sistema ruim, mantém-se a hegemonia do mercado, não há motivos econômicos para melhorar substancialmente o sistema, já que há quem o compre e o use sem grandes esforços de marketing. Além disso, existe uma “indústria da segurança” por trás disso. Além da M$, empresas como McAfee, Symantec, Trend Micro, entre outras, ganham fortunas oferecendo soluções paliativas para os problemas estruturais do janelas. Não espere que o janelas 7 seja muito melhor em termos de segurança do que seus antecessores, pois um sistema inseguro, mas hegemônico, é tudo o que a M$ e dezenas de empresas de segurança precisam para manter os acionistas felizes, e os usuários iludidos, mas igualmente felizes.

Os custos de desenvolvimento do kernel do Linux foi estimado em cerca de 614 milhões de dólares, e o de uma distribuição GNU/Linux típica em 1,2 bilhões de dólares. Esse capital não é investido por uma única empresa, mas diluído entre milhares (talvez milhões) de empresas e pessoas comuns ao redor do mundo, que contribuem com um pouco para que o sistema final chegue ao que se espera. Por isso é possível oferecer um sistema seguro a um preço irrisório. Não existe a preocupação com um ciclo de vida curto para garantir os lucros. Na verdade, a preocupação é exatamente oposta: ter um sistema estável e seguro para que se possa oferecer serviços constantes aos clientes. Sempre que uma versão nova do janelas é lançada, há uma demanda geral por novos treinamentos, novos equipamentos, novas “expertises“. No GNU/Linux, o ciclo é muito maior. Isso significa que quem usa uma versão 7.04 do Ubuntu, por exemplo, também usará uma versão 9.10, sem grandes dificuldades, porque na essência o sistema é o mesmo, mas as inovações se traduzem em mais compatibilidade, mais funcionalidades, mais segurança. Também não há grandes preocupações com a atualização do parque de máquinas porque a versão 9.10 rodará na maior parte das máquinas que rodavam a versão 7.04, por exemplo. Finalmente, não haverá a necessidade de uma urgente atualização do conhecimento dos técnicos de suporte, já que em essência, as mudanças são focadas na inovação, ou seja, não há mudança no conceito.

Aqui podemos ver uma situação curiosa: No sistema proprietário, não há mudança num conceito ruim que é perpetuado para que o “produto” continue a gerar lucros com mudanças “cosméticas”. Isso é bom para a empresa desenvolvedora, para as empresas de software incluídas no ecossistema. Não é tão bom para os técnicos porque precisam investir constantemente em treinamento, nem para os usuários que além do treinamento devem arcar com os custos do modelo (licenças de software diversas, treinamento constante, prejuízos decorrentes da insegurança do sistema, etc.). No sistema livre, o conceito originalmente bom, não tem a necessidade de ser modificado em profundidade, o que justifica mudanças que focam na inovação. Isso é bom para o ecossistema produtivo como um todo, já que diminui os custos tanto de desenvolvimento como o de treinamento de técnicos e usuários.

Como você pode observar, no sistema proprietário, a carga econômica fica com o consumidor final, bem como o ônus das deficiências do sistema. No sistema aberto, a carga é diluída entre todos e não há grandes ônus para nenhum dos envolvidos.

A questão comportamental.

Há uma tendência dos técnicos em afirmar que nenhum sistema é seguro, e que boa parte da segurança depende de quem o utiliza. Isso pode ser ou não uma verdade. Eu discordo de que isso seja uma verdade absoluta.

Partindo de uma instalação padrão, ou seja, uma que até seu sobrinho nerd poderia fazer, num sistema GNU/Linux é difícil para um “usuário padrão”, mesmo com comportamentos de risco, tornar o sistema vulnerável, a ponto de ser comparado aos sistemas janelas. Para fazer isso, ele teria de ter certos conhecimentos técnicos. Seria necessário habilitar o login automático do usuário root (o que por si só já é uma proeza), abrir todas as portas TCP e UDP fechadas por padrão (e para isso teria de instalar pacotes que não são instalados e/ou configurados por padrão), desabilitar o pedido de senha para ações consideradas “administrativas”, e/ou alterar os privilégios de usuário comum. Isso é bem mais do que um “usuário padrão” faria no janelas. No janelas, em uma instalação padrão, o administrador do sistema é quase que sugerido como usuário padrão. Um usuário não precisa se esforçar muito para abrir as poucas defesas existentes. Isso, aliado à insegurança inerente e aos comportamentos de risco (clicar em links suspeitos de email, entrar em sites de reputação duvidosa, instalar programas piratas de origem duvidosa, utilizar programas de downloads como bitorrent ou semelhantes, desabilitar a proteção por senhas do sistema para alterações no registro, não instalar atualizações, não saber como utilizar um antivirus, não usar o firewall, senhas pequenas e óbvias, etc.), tornam o janelas um verdadeiro problema para que o usa e uma ótima oportunidade para quem quer invadi-lo.

A falácia dos antivírus.

A maior ilusão de um usuário do janelas é pensar que um antivírus o salvará das pragas da Internet. Para se beneficiar da proteção oferecida pelos antivírus, são necessárias três condições adicionais:

• Conhecimento técnico para sua correta configuração, atualização e utilização (o que muito poucos detém);
• Utilização de softwares complementares como firewall e antispyware (o que também exige conhecimento técnico);
• Comportamentos seguros na utilização da Internet (o que exige treinamento e capacitação).

Se qualquer um dos três requisitos não for atendido, todo o resto será comprometido, ou seja, as várias centenas de reais gastos com toda essa parafernália será, literalmente, inútil.

As empresas de segurança há anos fingem que são capazes de oferecer proteção para seus clientes, mas têm absoluta certeza de que isso é uma batalha perdida, portanto, a única razão para continuarem a oferecer “soluções de segurança” é a existência de uma massa enorme de pessoas que as compram acreditando que elas tornarão seu sistema seguro. They don’t give a damn, they just want the money.

Recentemente, Eva Chen, uma das fundadoras da Trend Micro, concedeu uma entrevista onde afirma que os crackers estão na dianteira e que a indústria de antivírus é uma piada (de mal gosto). Portanto, se nem eles acreditam que poderão ganhar o jogo, porque você, que é o elo mais fraco, se arriscaria a bancá-lo?

Conclusão.

Existem vírus para Linux? Sim, existem mas, na prática, são completamente irrelevantes, pois não só é difícil de encontrá-los, como seu impacto é irrisório.

Se você não acredita que é possível existir um sistema seguro que dificulta ao máximo a infecção por vírus, o uso não autorizado da sua máquina, seja por crackers, seja por “empresas idôneas”, e que tira das suas costas grande parte da responsabilidade sobre a segurança dos seus dados e arquivos, deveria experimentar o GNU/Linux ou outro sistema aberto, como o FreeBSD. Não se trata de militância ideológica a favor de sistemas livres. Trata-se de resguardar o que é seu, seu patrimônio, sua privacidade e sua liberdade. É uma questão prática, não filosófica.

Porque pagar, ou usar ilegalmente um sistema que, notoriamente, é problemático e o expõe a riscos, os quais você nem mesmo dá conta da existência, nem tem condições de se proteger, se é possível ter um sistema seguro e gratuito?

Por que pagar por softwares “tapa buraco”, como os antivírus, que tapam o sol como uma peneira, se é possível ter um sistema que não necessita desses paliativos?

Pense bem sobre isso. E depois considere usar uma distribuição GNU/Linux.

One of the things I often do on FreeBSD machines is to install shells/mksh or shells/bash and work most of the time with a bourne-compatible shell.

The default /bin/csh shell is mostly ok for short interactive sessions, but I can’t stand its command-syntax for semi-complex looping, iteration or other combined commands. So install bash or mksh and I launch one of them from my login prompt, using something like:

csh# env SHELL=/usr/local/bin/bash /usr/local/bin/bash -l
bash# 

There’s a minor catch with SHELL being set to /usr/local/bin/bash though. The default binary of bash is dynamically linked, and it depends on libintl.so.XXX from the devel/gettext package. This means that if you happen to run a package update command that rebuilds gettext from source, there is a small period between the time the old gettext is uninstalled and the new version is installed that the following are all true:

• Your current SHELL points to bash
• The bash binary needs libintl.so.XXX to run, so it (temporarily) fails with a runtime linker error
• The “configure” script of the gettext sources thinks that configure-time checks can use your current SHELL
• Boom!…

So you cannot upgrade gettext, and your current shell needs it to run. Any other packages that depend on gettext cannot be upgraded either. Not a very nice corner to paint yourself into…

There are, however, at least three options to recover from a mess like this:

1. Run a shell that is statically linked version of bash. The shells/bash port of FreeBSD can build a statically linked version of the shell when WITH_STATIC_BASH is set at build-time.
2. Use /bin/csh or shells/mksh as a temporary shell to reinstall the broken packages, e.g. gettext and any other package that depends on it.
3. Set CONFIG_SHELL to a shell that works even without gettext (the /bin/sh shell of FreeBSD should work fine for this), or to one that has minimal library dependencies (the /usr/local/bin/mksh shell only depends on libc.so.X on FreeBSD, so it should work fine too).

Lately, I’ve been playing around with Mac OS X Snow Leopard in a virtual machine.  Hey, you have to try it before you diss it!

I’ll save my overall review for later, but I just wanted to get this out to everyone: MacPorts?  It’s no hack.  In fact, it can rival or beat most major ports implementations.

For those of you who don’t know what I’m talking about in terms of ‘ports’, it’s a generic name for a system that allows a user to rapidly download and install software from source.

While I originally thought MacPorts would be very hackish, at least compared to FreeBSD ports or even Gentoo’s Portage, the opposite may be true.  MacPorts is slick, smooth, reliable, has a very well chosen set of shell commands and options, and is in general excellent in nearly every way.  It excels at the one problem I’ve always had with ports systems — it is very hard to think out every angle for such a system, but MacPorts seems to do so almost completely.  So, everyone interested in making their own ports system?  Go try MacPorts, and learn from its awesomeness.

More info when I do a full OS X review!

Hace unos días descubrí los snapshots para filesystems UFS(2) de FreeBSD (lo se, lo se, soy un desastre) y si bien se implementa también para ZFS le di caña a los snapshots para UFS (default de FreeBSD).
Para probarlo, lo que hice fue crear y montar una imagen en un archivo (dd, mkfs, mdconfig, etc…) quedando algo así:

/home/ignacio $ mount | grep md0
/dev/md0 on /usr/home/ignacio/md0 (ufs, local)

Lo primero que hay que hacer, es notar la existencia del directorio .snap dentro de la recién montada imagen. Es en la raíz de cada partición UFS es donde está el directorio .snap.
Yo lo que hice fue instalar el frontend snapshot(8) mediante su port sysutils/freebsd-snapshot.

En la página citada, donde Ralf S. Engelschall explica la motivación y la forma de uso la verdad que está muy buena y simple.
Básicamente el comando snapshot, consta de cuatro acciones básicas: list, make, mount y umount.

Con snapshot list podemos ver la lista completa de los snapshots creados para alguna partición, en este caso, aún no hemos creado ninguno por lo que el listado, estará vacío:

/home/ignacio $ snapshot list /home/ignacio/md0
Filesystem          User   User%     Snap   Snap%  Snapshot

Vemos el listado actual del directorio actual:

/home/ignacio $ cd md0
/home/ignacio/md0 $ ls -l
drwxrwxr-x  2 root  operator      512 Nov 17 14:06 .snap
-rw-r--r--  1 root  wheel          12 Nov 10 16:23 ignacio
-rw-r--r--  1 root  wheel     1048576 Nov 10 17:37 test_file.txt

y creamos nuestro primer snapshot:

/home/ignacio/md0 $ snapshot make -g4 /home/ignacio/md0:snaps

Donde, -g4 indica que guardaremos 4 generaciones (cuatro vistas al pasado), /home/ignacio/md0 es (donde está montada) la partición y snaps es un tag que le asignamos.

Tiremos ahora un nuevo list:

/home/ignacio $ snapshot list /home/ignacio/md0
Filesystem          User   User%     Snap   Snap%  Snapshot
/home/ignacio/md0      2MB    2.9%    224KB    0.2%  snaps.0

Para jugar un poco borramos el archivo test_file.txt por error y ahora, para salvar el día, recuperamos el snapshot que creamos:

/home/ignacio/md0 $ ls -l
total 4
drwxrwxr-x  2 root  operator  512 Nov 17 14:09 .snap
-rw-r--r--  1 root  wheel      12 Nov 10 16:23 ignacio
/home/ignacio/md0 $

Para recuperar el snapshot debemos montarlo indicando que generación queremos recuperar, en nuestro caso, la 0:

/home/ignacio $ snapshot mount /home/ignacio/md0:snaps.0 /mnt
WARNING: opening backing store: /usr/home/ignacio/md0/.snap/snaps.0 readonly

Buscamos en el /mnt los archivos:

/home/ignacio $ cd /mnt
/mnt $ ls
.snap           ignacio         test_file.txt
/mnt $

Devolvemos test_file.txt a la normalidad:

/mnt $ cp -v test_file.txt /home/ignacio/md0
test_file.txt -> /home/ignacio/md0/test_file.txt
/ $ snapshot umount /mnt
/ $ cd /home/ignacio/md0
/home/ignacio/md0 $ ls -l
total 1044
drwxrwxr-x  2 root  operator      512 Nov 17 14:09 .snap
-rw-r--r--  1 root  wheel          12 Nov 10 16:23 ignacio
-rw-r--r--  1 root  wheel     1048576 Nov 17 14:14 test_file.txt

Con lo de arriba, copiamos el archivo que habiamos perdido por error, desmontamos el snapshot y verificamos como quedó nuestra partición.

En fin, terrible herramienta! Es recomendado revisar además la man page periodic-snapshot(8) para hacer snapshots periodicos usando el cron y periodic.

Estoy comenzando a ser un usuario feliz de este tipo de filesystems. Claro que ya tengo configurado el cron para que genere los snapshots de manera automatizada para todas las particiones de mi disco y también espero jamás en mi vida necesitarlos.

Вот полезные утилиты для мониторинга работы системы и поцессов с жесткими дисками:
gstat
top -m io -o total
lsof

Sistem Yöneticileri için yeni bir ipucu bloğu kuruldu. Sistem Yöneticisi olmak istiyorsanız gözatmakta fayda var. Zaman ilerledikçe bloğun içeriğinin zenginleşeceğini dolayısıylada kendisininde kalkınacağını düşünüyorum.

Link : http://sistemipucu.blogspot.com/