Alpine Linux:About: Difference between revisions

From Alpine Linux
(100% Done with Update (maybe))
Line 13: Line 13:
To answer that question, we must look to the origins of Alpine Linux.
To answer that question, we must look to the origins of Alpine Linux.


Alpine Linux began life as a fork of the [http://en.wikipedia.org/wiki/LEAF_Project LEAF Project]. The active members of the LEAF Project wanted to continue making a Linux distribution that ran off of a single floppy disk — and we think that's great — however, our needs required [http://en.wikipedia.org/wiki/Squid_%28software%29 Squid], [http://en.wikipedia.org/wiki/DansGuardian DansGuardian], [http://en.wikipedia.org/wiki/Samba_%28software%29 Samba], and a slew of other heavyweight applications. So, we ended up with a set of packages that fit on a CD-ROM.
Alpine Linux began life as a fork of the [http://en.wikipedia.org/wiki/LEAF_Project LEAF Project]. The active members of the LEAF Project wanted to continue making a Linux distribution that ran off of a single floppy disk — and we think that's great — however, our needs required Squid, DansGuardian], Samba, and a slew of other heavyweight applications. So, we ended up with a set of packages that fit on a CD-ROM.


The LEAF concept of "run from RAM" has a number of appealing features, especially on a firewall:
The LEAF concept of "run from RAM" has a number of appealing features, especially on a firewall:
Line 20: Line 20:
* If your configs are all on a write-protected floppy, recovering from a root-kit is as simple as rebooting.
* If your configs are all on a write-protected floppy, recovering from a root-kit is as simple as rebooting.


On the other hand, there were some things that we wanted to experiment with that weren't easy in the LEAF build environment at the time, such as:
On the other hand, there were some things that we wanted to experiment with that wasn't easy to do in the LEAF build environment at that time, such as:


* Complete build-from-source environment (e.g. Gentoo-style build world)
* A Complete Build-from-Source Environment (e.g. Gentoo-Style Build World)
* 2.6.x Kernel Support
* 2.6.x Kernel Support
* [http://en.wikipedia.org/wiki/Stack-smashing_protection Stack-Smashing support] from GCC
* Stack-Smashing Support (SSP) in GCC
* [http://en.wikipedia.org/wiki/PaX PaX] kernel security
* PaX Kernel Security
* Better package management with dependencies, upgrade path, pre- and post-install scripts, etc.
* Better package management with dependencies, upgrade path, pre- and post-install scripts, etc.


The project started from there. Our goal, however, has always been to be as simple as possible, keeping things very small. Alpine Linux won't quite fit on a floppy disk today, but it certainly runs from a 32MB USB stick.
And so the project began. Our goals, however, have always been to keep it as simple and small as possible. Alpine Linux won't quite fit on a floppy disk today, but it certainly runs from a 32MB USB stick.


== What's It Like? ==
== What's It Like? ==
Line 34: Line 34:
It started out Gentoo-style, but is now self-hosting. The network configuration is similar to Debian. If you've ever used a BusyBox-based system before, it's pretty good. The Alpine developers have contributed a number of enhancements to BusyBox, in an effort to make the system run like any other.
It started out Gentoo-style, but is now self-hosting. The network configuration is similar to Debian. If you've ever used a BusyBox-based system before, it's pretty good. The Alpine developers have contributed a number of enhancements to BusyBox, in an effort to make the system run like any other.


As it is a BusyBox-based system, there are no manpages by default; BusyBox applets do not have all of the features of their real counterparts. So, you will run into situations where things don't run like they do on a "real" Linux system. When you run into those situations, remember these two things:
As it is a BusyBox-based system, there are no manpages by default; BusyBox applets do not have all of the features of their real counterparts. So, you will run into situations where things don't run like they do on a "real" Linux system. When you run into those situations, just remember these two things:


* The base installation is good enough for a firewall/router; there's nothing there except the basics. You can probably get what you need out of it using the tools that are there, although crudely. ( sh / awk / sed / grep can do everything Perl can do... Really.)
* The base installation is small enough for a firewall/router; there's nothing there except the basics. You can probably get what you need out of it using the tools that are there, although crudely. ( sh / awk / sed / grep can do everything Perl can do... Really.)
* Alpine has a complete set of packages, but you will need to explicitly choose what you wish to install.
* Alpine has a complete set of packages, but you will need to explicitly choose what you wish to install.


Line 47: Line 47:
* '''It's more secure:''' When The Linux 0-day vmsplice vulnerability was causing admins everywhere to upgrade their kernels post-haste, Alpine Linux systems were basically impervious. Yes, the code crashed the application, but the PaX protection prevented system compromise. The value of PaX and SSP has been proven on more than one occasion.
* '''It's more secure:''' When The Linux 0-day vmsplice vulnerability was causing admins everywhere to upgrade their kernels post-haste, Alpine Linux systems were basically impervious. Yes, the code crashed the application, but the PaX protection prevented system compromise. The value of PaX and SSP has been proven on more than one occasion.
* '''It's simple:''' Once you get past the package management, and the fact that changes are not saved unless you do a "<code>lbu commit</code>" (on run-from-RAM installs only), it really is much simpler to manage.
* '''It's simple:''' Once you get past the package management, and the fact that changes are not saved unless you do a "<code>lbu commit</code>" (on run-from-RAM installs only), it really is much simpler to manage.
* '''It supports [http://linux-vserver.org/ Linux VServer]:''' You can run virtualized hosts on it, similar to FreeBSD Jails. You can even run them under a run-from-RAM install. Albeit, not very practical, but worth geek points!
* '''It supports [http://linux-vserver.org/ Linux VServer]:''' You can run virtualized hosts on it, similar to FreeBSD Jails. (You can even run them in a run-from-RAM install. Although it's not very practical, it is worth geek points!)


== What Do I Need to Watch Out For? ==
== What Do I Need to Watch Out For? ==


* The package system is different. You need to learn about apk before you can manage a system effectively
Basically, you should know that...
* Everything is in RAM. You lose everything if you don't save your configs somewhere. You need to learn about lbu. Even then, keep in mind that by default lbu only backs up things in /etc. You can change this, but you need to know about lbu.
 
* OpenRC isn't like /etc/init.d. OpenRC makes things boot fast really fast. But you need to know how to get openrc to add your daemons to the startup process.
* Alpine Linux uses [[Alpine Linux package management|apk-tools]] for its package management system. You need to learn about [[Alpine Linux package management|apk]] before you can manage the system effectively.
* We are engineers, not documenters. There's not alot of documentation out there. Well, there is - if you believe "RTFM" is documentation. We're working on it - and could use help! But in many cases, things are not documented as well as they should be.
* Alpine Linux uses [[Alpine Linux init system|OpenRC]] for its init system. You will need to know how to get OpenRC to add daemons to the startup process.
* Alpine Linux uses [[Alpine local backup|lbu]] on run-from-RAM installs so you don't lose everything between reboots. Keep in mind that, by default, lbu only backs up things in /etc. You can change this behavior, but you will need to know about lbu.
* We are engineers, not documenters. There's not alot of documentation out there (yet). Well, there is, if you believe "RTFM" is documentation. We're working on it and could use help! But in many cases, things are not documented as well as they should be.


== Why the Name Alpine? ==
== Why the Name Alpine? ==


Alpine originally stood for A Linux Powered Itegrated Network Engine. The idea was that the distro would be focused on networking, and be a tiny "engine" or framework to build bigger systems on. Today, Alpine lives up to that name. The first open source implementation of Cisco's DMVPN was written for Alpine Linux. Improvements to networking functions in the Linux Kernel have started from patches or needs from the Alpine Linux team.
Alpine originally stood for A Linux Powered Integrated Network Engine. The idea was that the distro would be focused on networking, and be a tiny "engine" or framework with which to build bigger systems on. Today, Alpine lives up to that name. The first open source implementation of Cisco's DMVPN, called [http://sourceforge.net/projects/opennhrp/ OpenNHRP], was written for Alpine Linux. Improvements to networking functions in the Linux Kernel have started from patches or needs from the Alpine Linux team.


On the other hand, there are a number of installations where Alpine Linux is used as the basis for enterprise servers running Postgresql, Postfix, Asterisk, Kamailio, iSCSI SAN. It is the little engine that could.
On the other hand, there are a number of installations where Alpine Linux is used as the basis for enterprise servers running PostgreSQL, Postfix, Asterisk, Kamailio, and iSCSI SANs, to name a few. It is the little engine that could.


Anymore, Alpine is just a name.
Nowadays, Alpine is just a name.

Revision as of 20:40, 4 August 2010

Alpine Linux is a community-developed operating system designed for x86 Routers, Firewalls, VPNs, VoIP and servers.

Alpine Linux is and always will be free of charge. You do not pay any licensing fees. You can download, use and share Alpine Linux with anyone for absolutely nothing.

Alpine Linux was designed with security in mind. It has proactive security features, such as PaX and SSP, that prevent security holes from being exploited.

Alpine Linux uses the uClibc C library and all of the base tools from BusyBox. These are normally found on embedded systems and are smaller than the tools found on GNU/Linux systems.

Why Another Distribution?

To answer that question, we must look to the origins of Alpine Linux.

Alpine Linux began life as a fork of the LEAF Project. The active members of the LEAF Project wanted to continue making a Linux distribution that ran off of a single floppy disk — and we think that's great — however, our needs required Squid, DansGuardian], Samba, and a slew of other heavyweight applications. So, we ended up with a set of packages that fit on a CD-ROM.

The LEAF concept of "run from RAM" has a number of appealing features, especially on a firewall:

  • If your configs are all on a floppy, an upgrade is as simple as burning a new CD and rebooting.
  • If your configs are all on a write-protected floppy, recovering from a root-kit is as simple as rebooting.

On the other hand, there were some things that we wanted to experiment with that wasn't easy to do in the LEAF build environment at that time, such as:

  • A Complete Build-from-Source Environment (e.g. Gentoo-Style Build World)
  • 2.6.x Kernel Support
  • Stack-Smashing Support (SSP) in GCC
  • PaX Kernel Security
  • Better package management with dependencies, upgrade path, pre- and post-install scripts, etc.

And so the project began. Our goals, however, have always been to keep it as simple and small as possible. Alpine Linux won't quite fit on a floppy disk today, but it certainly runs from a 32MB USB stick.

What's It Like?

It started out Gentoo-style, but is now self-hosting. The network configuration is similar to Debian. If you've ever used a BusyBox-based system before, it's pretty good. The Alpine developers have contributed a number of enhancements to BusyBox, in an effort to make the system run like any other.

As it is a BusyBox-based system, there are no manpages by default; BusyBox applets do not have all of the features of their real counterparts. So, you will run into situations where things don't run like they do on a "real" Linux system. When you run into those situations, just remember these two things:

  • The base installation is small enough for a firewall/router; there's nothing there except the basics. You can probably get what you need out of it using the tools that are there, although crudely. ( sh / awk / sed / grep can do everything Perl can do... Really.)
  • Alpine has a complete set of packages, but you will need to explicitly choose what you wish to install.

Why Should I Try It?

We're partial, of course, but here are a few reasons:

  • It's quick: You can run it from a USB stick and have a very usable system in less than 10 minutes.
  • It's great for experimenting: Since the configuration system stores everything in one file, you can take that file to a larger server and extract the configuration there.
  • It's more secure: When The Linux 0-day vmsplice vulnerability was causing admins everywhere to upgrade their kernels post-haste, Alpine Linux systems were basically impervious. Yes, the code crashed the application, but the PaX protection prevented system compromise. The value of PaX and SSP has been proven on more than one occasion.
  • It's simple: Once you get past the package management, and the fact that changes are not saved unless you do a "lbu commit" (on run-from-RAM installs only), it really is much simpler to manage.
  • It supports Linux VServer: You can run virtualized hosts on it, similar to FreeBSD Jails. (You can even run them in a run-from-RAM install. Although it's not very practical, it is worth geek points!)

What Do I Need to Watch Out For?

Basically, you should know that...

  • Alpine Linux uses apk-tools for its package management system. You need to learn about apk before you can manage the system effectively.
  • Alpine Linux uses OpenRC for its init system. You will need to know how to get OpenRC to add daemons to the startup process.
  • Alpine Linux uses lbu on run-from-RAM installs so you don't lose everything between reboots. Keep in mind that, by default, lbu only backs up things in /etc. You can change this behavior, but you will need to know about lbu.
  • We are engineers, not documenters. There's not alot of documentation out there (yet). Well, there is, if you believe "RTFM" is documentation. We're working on it and could use help! But in many cases, things are not documented as well as they should be.

Why the Name Alpine?

Alpine originally stood for A Linux Powered Integrated Network Engine. The idea was that the distro would be focused on networking, and be a tiny "engine" or framework with which to build bigger systems on. Today, Alpine lives up to that name. The first open source implementation of Cisco's DMVPN, called OpenNHRP, was written for Alpine Linux. Improvements to networking functions in the Linux Kernel have started from patches or needs from the Alpine Linux team.

On the other hand, there are a number of installations where Alpine Linux is used as the basis for enterprise servers running PostgreSQL, Postfix, Asterisk, Kamailio, and iSCSI SANs, to name a few. It is the little engine that could.

Nowadays, Alpine is just a name.