FreeBSD - remove all installed packages!

pkg_info | cut -d\ -f1 | xargs pkg_delete

or

cd /var/db/pkg ; find . -type d | xargs pkg_delete

The punkiest site is back! http://hacker.com.br/

Good reads!

# SED: FIND REPLACE

# sed -i '' -e 's/-bkp/_bkp/g' COAD.SQL

Firewall options on FreeBSD

# firewall
device pf
options ALTQ
options ALTQ_CBQ
options ALTQ_RED
options ALTQ_RIO
options ALTQ_HFSC
options ALTQ_CDNR
options ALTQ_PRIQ

# hardware monitor
device smbus
device iicbus
device iicbb
device intpm
device smb

Schedulers and building kernels

ULE vs. 4BSD

The ULE scheduler was recently introduced and provides similar pre-emptiveness to that of the 2.6 Linux kernel. The ULE scheduler was initially rolled out during the 5.x series; however, due to system instability the default scheduler was reverted to the classic 4BSD scheduler. The ULE scheduler still isn’t enabled by default, as proven by the fact that its configuration line is commented out in the default kernel config file. The adventurous may choose to uncomment the ULE scheduler, and comment out the 4BSD scheduler and rebuild their kernels.

Compiling the kernel

Compiling FreeBSD’s kernel will be a little bit different for those used to compiling Linux kernels. There is no graphical, or semi-graphical text based interface to select the various parameters: as with many other things in FreeBSD a single, simple text file will do the trick. The default kernel configuration files are located in /usr/src/sys/{YOUR_ARCH} where arch will most likely be i386 or amd64. It is highly recommended to copy the GENERIC file to a safe location, like /root/config/kernel/MYKERNEL and then symlink it back to /usr/src/sys. This is to prevent the accidental deletion of your config if you decided to blow away /usr/src.

The name of the kernel config file is not enough to distinguish it from other kernel configuration files; instead the IDENT line must be changed to reflect the name you choose for your configuration, MYKERNEL in this particular case (for this article).

To build and install the kernel with your custom config, simply change directories to /usr/src and invoke make buildkernel KERNCONF=MYKERNEL. The command to install the newly built kernel is similar: make installkernel KERNCONF=MYKERNEL.

# Should be changed to the identifier of your custom config
ident    GENERIC
-- Becomes --
ident    MYKERNEL

# Scheduler Options
#options        SCHED_ULE               # ULE scheduler
options         SCHED_4BSD              # 4BSD scheduler (This is the classic scheduler)


cd /usr/src
make buildkernel KERNCONF="KERN_LABEL"
make installkernel KERNCONF="KERN_LABEL"

Remove ^M from windows text files with VI.


:1,$s/^V^M//gc

or

:1,$!tr -d '\r'


ssh-keygen: password-less SSH login

SSH is often used to login from one system to another without requiring passwords.

A number of methods may be used for that to work properly, one of which is to setup a .rhosts file (permission 600) with its content being the name of the remote system you trust, followed by the username your trust:

hacker.com.br user

would mean you trust user cantin from hacker.com.br to connect to your account, without requiring a password.

But for that to work, SSH itself must be configured to trust .rhosts files (which it does not for most OpenSSH installations - but we do on most systems RCSG maintains), and the private/public key pair of each system must be properly set in the system-wide ssh_known_hosts public key file.

This, of course, requires help from the local systems administrator.

The second method does not require any help from the systems administrator. And it does not require modifications to the .rhosts file. Instead, it requires you generate your own personal set of private/public pair.

ssh-keygen is used to generate that key pair for you. Here is a session where your own personal private/public key pair is created:

user@theory:~> ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ttaranto/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/ttaranto/.ssh/id_rsa.
Your public key has been saved in /home/ttaranto/.ssh/id_rsa.pub.
The key fingerprint is:
f6:61:a8:27:35:cf:4c:6d:13:22:70:cf:4c:c8:a0:23 ttaranto@hacker.com.br

The command ssh-keygen -t rsa initiated the creation of the key pair.

No passphrase was entered (Enter key was pressed instead).

The private key was saved in .ssh/id_rsa. This file is read-only and only for you. No one else must see the content of that file, as it is used to decrypt all correspondence encrypted with the public key.

The public key is save in .ssh/id_rsa.pub.

In this case, the content of file id_rsa.pub is

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEArkwv9X8eTVK4F7pMlSt45pWoiakFkZMw
G9BjydOJPGH0RFNAy1QqIWBGWv7vS5K2tr+EEO+F8WL2Y/jK4ZkUoQgoi+n7DWQVOHsR
ijcS3LvtO+50Np4yjXYWJKh29JL6GHcp8o7+YKEyVUMB2CSDOP99eF9g5Q0d+1U2WVdB
WQM= user@theory

It is one line in length.

Its content is then copied in file .ssh/authorized_keys of the system you wish to SSH to without being prompted for a password.

The example shown here generated keys on sodium by user cantin. If the public key generated, file .ssh/id_rsa.pub, was copied to your account, file .ssh/authorized_keys on hacker.com.br, then user user@theory is allowed to SSH into your own account on hacker.com.br without the use of a password.

To summarize, a personal private/public key pair is generated using the ssh-keygen command. The public key is then copied onto a remote systems' .ssh/authorized_keys file. And you can now SSH to the remote systems's account without the use of a password.