Difference between pages "Funtoo:User Services/Containers" and "Repository Configuration"

From Funtoo
< Funtoo:User Services(Difference between pages)
Jump to navigation Jump to search
 
 
Line 1: Line 1:
== Funtoo Linux Hosting ==
{{Warning|This article is a work-in-progress referring to a future Portage version. It does not apply to the current Funtoo Portage version. Please do not update your configuration yet.}}


If you support Funtoo Linux, we also want to support ''you'' in your Funtoo Linux adventure. Supporters of Funtoo Linux of at least $15/mo can request a Funtoo Linux virtual container. Here are the configurations currently being offered:
Starting with Portage-2.3.8, a switch to a new repository configuration framework is complete and users may want to update their configuration files. This document aims to describe the goals for the new framework and how to use it.


* $15/mo : '''4GB''' RAM, '''6''' CPU threads, 50GB disk
== Multiple repository layout ==
* $30/mo : '''12GB''' RAM, '''12''' CPU threads, 100GB disk
One of the most important changes is the switch from the old ''overlay'' layout to a new cleaner ''repository'' system. The new layout is more flexible and more predictable. For example, repositories can now use resources (eclasses, for example) provided by other repositories.
* $45/mo : '''48GB''' RAM, '''24''' CPU threads, 200GB disk


As you can see, this pricing is well below market rates, and includes fast SSD (solid state disk) storage, one IPv4 address, and lots of bandwidth. We believe that by enabling you to do with great things with Funtoo Linux, our community and technology will benefit. So we see this as a win for everyone.
The old layout was based on the concept of one ''main tree'' and optionally a number of overlays. The main tree provided base system ebuilds, eclasses, profiles, while overlays mostly were able to provide their own ebuilds. The ebuild provided by overlays overrode the ebuilds in main tree to the extend of making it impossible to install the main tree version. Overlays could also provide eclasses for their own ebuilds and package.* entries that applied to all overlays and to the main tree. The Package Manager is responsible for updating the main tree, while overlays are managed externally.


== Container FAQ ==
The new layout is based on the concept of one or more configurable repositories. Each repository can either be stand-alone or depend upon other repositories. The distribution provides a repository called ''funtoo'' (a drop-in replacement for Gentoo's ''gentoo'' repository). Users can install more repositories at they will, the repositories providing their own ebuilds, eclasses and profiles as necessary and/or using them from other repositories. Users can explicitly choose the repository they want to install packages from. The Package Manager can update all repositories.


;How do I sign up?: Set up a monthly support subscription via PayPal or credit card on our [[Support Funtoo]] page. Then see the [[#Getting Started|Getting Started]] section below.
== Portage configuration ==
=== New repository layout ===
The repository configuration should be stored in <code>/etc/portage/repos.conf</code>. It can be either a single file or a directory containing one or more ''.conf'' files.


;Do I get root access?: Yes, you get full root access to your container.
The default configuration is installed as <code>/usr/share/portage/config/repos.conf</code>. This file is internal configuration file installed with portage ebuild and should '''not''' be modified. Instead, the configuration in <code>/etc/portage/repos.conf</code> can override the defaults specified there.


;Can I reboot my container?: Yes, reboot normally and it will come back up.
The configuration uses format similar to Windows .ini files. Each section heading (repository name in square brackets) signifies a single repository, followed by one or more key-value option pairs. For example, the following file copies default configuration for Funtoo repository:


;How much bandwidth is ''really'' included?: Practically unlimited. Please let me know if you plan to go over several hundred gigabytes of traffic per month.
{{file|name=/etc/portage/repos.conf/funtoo.conf|desc=Example configuration override for Funtoo repository|body=
[funtoo]
# moved to non-default location!
location = /var/db/repos/funtoo
sync-type = git
sync-uri = git://github.com/funtoo/ports-2015.git
auto-sync = yes
}}
Location variable is now what used to be a PORTDIR, when using old-fashioned <code>/etc/portage/make.conf</code>.  <code>/var/db/repos/funtoo</code> is a dummy location example. Default location in Funtoo is  set to <code>/usr/portage</code>. Users are free to choose a location of their suits. sync-type is a CVS tree used for portage tree, git is a default in Funtoo. sync-uri is what used to be a SYNC variable, when using old-fashioned configuration through <code>/etc/portage/make.conf</code>
The most useful repository configuration options are listed below:
;location: ''Obligatory.'' Specifies the directory where repository is/will be stored. If Portage knows how to sync the repository and the location does not exist, it will be created on next ''emerge --sync''. Otherwise, the directory must exist.
;priority: Specifies the priority used for ordering ebuilds from different repositories. If two repositories provide an ebuild with matching versions, the repository with higher priority will be used.
;auto-sync: Specifies whether ''emerge --sync'' should update the repository. Defaults to ''yes'' if ''sync-type'' is specified, ''no'' otherwise.
;sync-depth: Specifies ''--depth'' for git clone. Used only on initial sync. Defaults to 1. Can be set to 0 to force full clone (not pass ''--depth'' at all).
;sync-type: Specifies syncing/update method. Can be one of: ''cvs'', ''git'', ''rsync'', ''svn''.
;sync-umask: Specifies the umask used when updating/syncing the repository.
;sync-uri: Specifies remote URI from which the repository will be cloned/synced. Can use any syntax valid for a particular syncing method.
;sync-user: Specifies the user[:group] used to update/sync the repository. If ''FEATURES=usersync'' is used, defaults to the credentials of directory owner.


;How do I upgrade the kernel in my VPS?: A virtual container shares a kernel with the host, so you do not have the ability to change the kernel from "inside" the container.
[[Category:Portage]]
 
;Can I run Docker inside my container?: The OpenVZ development team is the largest code contributor to the Linux Containers kernel code (which is part of Docker,) and we use OpenVZ, but right now it is not possible to run LXC inside an OpenVZ container. This may change with the release of newer OpenVZ kernels based on 3.x.
 
{{fancyimportant|This next bit of information is important. A number of people have temporarily locked themselves out of their containers by setting up a firewall incorrectly. I plan to develop a firewall management UI that configures a firewall for you to make this step easier. For the time being, please avoid setting up a firewall unless you ''really'' need one.}}
 
;Can I set up my own firewall?: Before you do, please contact me (Daniel) and let me know. I need to flip a few switches in your container to make iptables work properly. Otherwise it will silently fail on stateful firewalls and you may end up locking yourself out of your container.
 
== Getting Started ==
 
Once you have [[Support Funtoo|signed up for Funtoo Monthly support]], contact me (drobbins@funtoo.org) and request a virtual container. You'll need to send me two things:
 
# The hostname you'd like for your container. It will be ''something''.host.funtoo.org.
# Attach your SSH public key. I will use this to grant you root access to your container.
 
== Generating SSH Keys ==
To generate an SSH key pair, do this as the user that you'll be using to log in to your container:
 
$ ssh-keygen -t rsa
 
If you specify a passphrase when prompted, your local private key (~/.ssh/id_rsa) will be encrypted, and ssh will prompt you for this passphrase prior to connecting. If you don't specify a passphrase, then you won't need to enter anything to connect but it you need to be extra careful that you don't allow others to access your private key.
 
The file you will need to send me is ~/.ssh/id_rsa.pub or ~/.ssh/id_dsa.pub. This is the public key... it's safe to send over email since all I or anyone else can use it for is to grant you access to a system using your private key. Just don't send your private key to me.
 
== Policies ==
 
{{Policies}}
 
=== VPS Usage Rules ===
 
{{fancyimportant|Please read these policies and make sure you understand them. This is not an exhaustive list.}}
 
The VPS is for '''your personal use'''. No reselling.
 
There is currently no Web panel - these servers will be set up using my own automated tool and you will be provided with ssh access. I can periodically reload VPS images as needed.
 
This service is offered as a thank-you gift to Funtoo Linux supporters as long as sufficient capacity is available, with no warranty for uptime or anything else.
 
There are no refunds.
 
While I host several production sites on this infrastructure, you assume all risk for hosting your production services on your VPS.
 
I will make a best-effort-only attempt to provide support via IRC and email, and do not offer 24/7 support for your VPS.
 
'''US-Legal activities only. No spam will be tolerated.'''
 
These VPS systems are intended for funtoo enthusiasts only. I am providing (particularly in the higher-level plans) generous default resource limits with the understanding that the VPS will be used for general Funtoo use and server stuff.
 
Compiling with -j(NUM-CPUS+1) is encouraged (this is Funtoo, after all -- I want you to enjoy fast compiles :), but it's not okay to continually max CPU, IO, or network utilization. '''So, no folding@home, massive file sharing, etc. '''
 
I am currently not supporting IPv6 but will look into adding such support if there is enough interest.
 
'''You are responsible for backups. '''
 
I reserve the right to change plans and pricing in the future.

Revision as of 13:52, February 14, 2015

   Warning

This article is a work-in-progress referring to a future Portage version. It does not apply to the current Funtoo Portage version. Please do not update your configuration yet.

Starting with Portage-2.3.8, a switch to a new repository configuration framework is complete and users may want to update their configuration files. This document aims to describe the goals for the new framework and how to use it.

Multiple repository layout

One of the most important changes is the switch from the old overlay layout to a new cleaner repository system. The new layout is more flexible and more predictable. For example, repositories can now use resources (eclasses, for example) provided by other repositories.

The old layout was based on the concept of one main tree and optionally a number of overlays. The main tree provided base system ebuilds, eclasses, profiles, while overlays mostly were able to provide their own ebuilds. The ebuild provided by overlays overrode the ebuilds in main tree to the extend of making it impossible to install the main tree version. Overlays could also provide eclasses for their own ebuilds and package.* entries that applied to all overlays and to the main tree. The Package Manager is responsible for updating the main tree, while overlays are managed externally.

The new layout is based on the concept of one or more configurable repositories. Each repository can either be stand-alone or depend upon other repositories. The distribution provides a repository called funtoo (a drop-in replacement for Gentoo's gentoo repository). Users can install more repositories at they will, the repositories providing their own ebuilds, eclasses and profiles as necessary and/or using them from other repositories. Users can explicitly choose the repository they want to install packages from. The Package Manager can update all repositories.

Portage configuration

New repository layout

The repository configuration should be stored in /etc/portage/repos.conf. It can be either a single file or a directory containing one or more .conf files.

The default configuration is installed as /usr/share/portage/config/repos.conf. This file is internal configuration file installed with portage ebuild and should not be modified. Instead, the configuration in /etc/portage/repos.conf can override the defaults specified there.

The configuration uses format similar to Windows .ini files. Each section heading (repository name in square brackets) signifies a single repository, followed by one or more key-value option pairs. For example, the following file copies default configuration for Funtoo repository:

   /etc/portage/repos.conf/funtoo.conf - Example configuration override for Funtoo repository
[funtoo]
# moved to non-default location!
location = /var/db/repos/funtoo
sync-type = git
sync-uri = git://github.com/funtoo/ports-2015.git
auto-sync = yes

Location variable is now what used to be a PORTDIR, when using old-fashioned /etc/portage/make.conf. /var/db/repos/funtoo is a dummy location example. Default location in Funtoo is set to /usr/portage. Users are free to choose a location of their suits. sync-type is a CVS tree used for portage tree, git is a default in Funtoo. sync-uri is what used to be a SYNC variable, when using old-fashioned configuration through /etc/portage/make.conf The most useful repository configuration options are listed below:

location
Obligatory. Specifies the directory where repository is/will be stored. If Portage knows how to sync the repository and the location does not exist, it will be created on next emerge --sync. Otherwise, the directory must exist.
priority
Specifies the priority used for ordering ebuilds from different repositories. If two repositories provide an ebuild with matching versions, the repository with higher priority will be used.
auto-sync
Specifies whether emerge --sync should update the repository. Defaults to yes if sync-type is specified, no otherwise.
sync-depth
Specifies --depth for git clone. Used only on initial sync. Defaults to 1. Can be set to 0 to force full clone (not pass --depth at all).
sync-type
Specifies syncing/update method. Can be one of: cvs, git, rsync, svn.
sync-umask
Specifies the umask used when updating/syncing the repository.
sync-uri
Specifies remote URI from which the repository will be cloned/synced. Can use any syntax valid for a particular syncing method.
sync-user
Specifies the user[:group] used to update/sync the repository. If FEATURES=usersync is used, defaults to the credentials of directory owner.
Retrieved from "https://www.funtoo.org/index.php?title=Funtoo:User_Services/Containers&oldid=9036"