Difference between pages "SFTP Only Access" and "Updating Ebuilds"

(Difference between pages)
(Quick start)
 
 
Line 1: Line 1:
== Context ==
+
=== Updating Ebuilds ===
  
In some cases, it can be useful to set up an access on your Funtoo box such as a user:
+
Updating ebuilds is important. Our forked ebuilds in Funtoo Linux will go stale if they are not updated periodically, so we want to periodically bump them to new versions. Exceptions are gcc, glibc, binutils, linux-headers, python, perl and ruby and possibly a few other "core" ebuilds that we bump a few times a year in a coordinated fashion. But all other ebuilds in our tree need regular updates.
* does not see the whole contents of the machine but, instead, remains "jailed" in a home directory
+
* is able to transfer files back and forth on the box via SFTP
+
* does not have access to a shell
+
  
Such a SFTP only access is easy to setup:
+
==== Overview ====
  
# Assign a group (e.g. ''sftponly'') to users that must be restricted to a SFTP-only account
+
The basic process is as follows:
# Change a bit the configuration of OpenSSH so that users belonging to your sftp-only group are given a chrooted access
+
# Make OpenSSH ignore any other command than running sftp-server on the server side for users belonging to your sftp-only group (this is where the trick lies !)
+
  
== Quick start ==
+
# Create new ebuild
 +
# Add ebuild masked for testing using <tt>profiles/package.mask/funtoo-staging</tt>
 +
# Request testing on the funtoo-dev mailing list
 +
# Move to Funtoo Linux current
 +
# Move to Funtoo Linux stable
  
First, a dedicated group must be created. For the sake of the example we use sftponly here, use whatever name fits your preferences:
+
Be sure to check the history of the ebuild in funtoo by typing "<tt>git log .</tt>" and "<tt>git log -p .</tt>" in the ebuild's directory, to get an idea of why we forked it. If you have any questions, check with Daniel on IRC or via email (staff or funtoo-dev ML).
<console>
+
###i## groupadd sftponly
+
</console>
+
  
Next in the configuration of OpenSSH (located in <code>/etc/sshd/sshd_config</code>) locate:
+
{{fancyimportant|There is no problem pulling in the current ebuild from Gentoo ''as long as'' any existing funtoo changes are applied to the new ebuild.}}
<pre>
+
Subsystem      sftp    /usr/lib64/misc/sftp-server
+
</pre>
+
and change it to:
+
<pre>
+
Subsystem      sftp    internal-sftp
+
</pre>
+
  
Now the $100 question: ''"how can OpenSSH can be told to restrict a user access to a simple sftp session?"'' Simple! Assuming that ''sftponly'' is the group you use for for your restricted users, just add to the file <code>/etc/sshd/sshd_config</code> the following statement:
+
==== Steps to determine Funtoo changes ====
  
<console>
+
# <tt>diff -uRN <i>matching-gentoo-version</i> <i>funtoo-version</i></tt>
###i## nano /etc/sshd/sshd_config
+
# Note any differences on the Funtoo side; these should be preserved.
# Restricted users, no TCP connexions bouncing, no X tunneling.
+
# Create new funtoo version based on new gentoo version, with Funtoo changes/patches applied.
Match group sftponly
+
        ChrootDirectory /home/%u
+
        X11Forwarding no
+
        AllowTcpForwarding no
+
        ForceCommand internal-sftp
+
</console>
+
  
To understand how it works, you must be aware that, when you open an SSH session, the SSHD process launch a process on the server side which could be:
+
Note that often times, there are no significant changes on the Gentoo side, so the best course of action is to:
* a shell => ssh <code>login@host</code>
+
* a kind of dedicated ftp daemon (sftp-server) => sftp <code>user@host</code>
+
  
{{Note}}TBC
+
# <tt>cp <i>funtoo-version</i> <i>new-funtoo-version</i></tt>
 +
# tweak <i>new-funtoo-version</i> as necessary.
  
[[Category:HOWTO]]
+
The general principle for lightly-Funtoo-modified ebuilds is that we want to apply any necessary or recommended upstream Gentoo changes, within reason, while preserving the Funtoo modifications that have been made.
 +
 
 +
The general principle for heavily-Funtoo-modified ebuilds is to understand the scope of the Funtoo changes and what Daniel is trying to do with the ebuild. Often times I am removing cruft from overly-complicated ebuilds to make them more maintainable. A lot of times, I have completely rewritten or redesigned ebuilds. In these cases, we want to look at the Gentoo ebuild more for ideas and for new patches that we might want to consider, but not be so hasty to apply them. We want to apply them only if they make sense for our plans for the ebuild.
 +
 
 +
==== Steps After Ebuilds Are Updated ====
 +
 
 +
If you have updated the ebuild to Funtoo standards, and are comfortable that it is ready for inclusion in Funtoo Linux, then follow these steps. If the ebuild is not ready yet, be sure to follow-through and either hand off the ebuild to someone else or check with Daniel to get your questions answered so it can be completed.
 +
 
 +
General steps to follow once the ebuild is ready for inclusion in Funtoo:
 +
 
 +
# Masking - Mask the ebuild in <tt>profiles/package.mask/funtoo-staging</tt> - put your masks at the top of the file (reverse chronological order.)
 +
# Communicate - Post to the funtoo-dev mailing list and forums announcing the new masked ebuilds, noting that they are available for testing.
 +
# Monitor - Monitor community resources for success or failure reports for testing.
 +
# If we have sufficient positive replies, and no outstanding issues, move to Funtoo Linux current.
 +
# After a period of 2-3 days, move to Funtoo Linux stable.
 +
 
 +
==== The List ====
 +
 
 +
{{fancyimportant|If you are going to do one of these things, put your name after it so others know :)}}
 +
 
 +
Here's a list of ebuilds that need updating:
 +
 
 +
* dhcpcd-5.2.11 (or later?) [golodhrim] {already in portage and stable newer versions will follow}
 +
* gdisk-0.6.14 [angry_vincent] {already in portage for testing} / [404_Error] {Functional on sparc64, not to be used with system disks due to OpenBoot incompatibilities}
 +
* bash [angry-vincent] {already in portage for testing}
 +
* tar-1.25+ [angry_vincent] (tar-1.24 had problems with device nodes creation, this is fixed in >=tar-1.25, testing with metro builds) / [404_Error] {Remains to be tested on sparc64}
 +
* sandbox-2.5 (needs some testing in metro) [angry-vincent/golodhrim] {testing running/golodhrim testing done, working perfect in metro} / [404_Error] {Remains to be tested on sparc64}
 +
* klibc-1.5.20 (test with uvesafb)
 +
* dev-lang/perl-5.12.2-r6 [404_error] {already in portage for testing, no issues on sparc64 and amd64 at deployment, perl-cleaner passes, remains to be tested in the long term especially with day to day usage}, -r2 suffers of a parallelism issue
 +
 
 +
Stuff I (drobbins) can handle:
 +
 
 +
* feedparser-5.0.1
 +
* openvz-sources
 +
* genkernel {QSG written, some parts to be completed}
 +
 
 +
__NOTITLE__

Revision as of 04:21, April 3, 2011

Updating Ebuilds

Updating ebuilds is important. Our forked ebuilds in Funtoo Linux will go stale if they are not updated periodically, so we want to periodically bump them to new versions. Exceptions are gcc, glibc, binutils, linux-headers, python, perl and ruby and possibly a few other "core" ebuilds that we bump a few times a year in a coordinated fashion. But all other ebuilds in our tree need regular updates.

Overview

The basic process is as follows:

  1. Create new ebuild
  2. Add ebuild masked for testing using profiles/package.mask/funtoo-staging
  3. Request testing on the funtoo-dev mailing list
  4. Move to Funtoo Linux current
  5. Move to Funtoo Linux stable

Be sure to check the history of the ebuild in funtoo by typing "git log ." and "git log -p ." in the ebuild's directory, to get an idea of why we forked it. If you have any questions, check with Daniel on IRC or via email (staff or funtoo-dev ML).

Important

There is no problem pulling in the current ebuild from Gentoo as long as any existing funtoo changes are applied to the new ebuild.

Steps to determine Funtoo changes

  1. diff -uRN matching-gentoo-version funtoo-version
  2. Note any differences on the Funtoo side; these should be preserved.
  3. Create new funtoo version based on new gentoo version, with Funtoo changes/patches applied.

Note that often times, there are no significant changes on the Gentoo side, so the best course of action is to:

  1. cp funtoo-version new-funtoo-version
  2. tweak new-funtoo-version as necessary.

The general principle for lightly-Funtoo-modified ebuilds is that we want to apply any necessary or recommended upstream Gentoo changes, within reason, while preserving the Funtoo modifications that have been made.

The general principle for heavily-Funtoo-modified ebuilds is to understand the scope of the Funtoo changes and what Daniel is trying to do with the ebuild. Often times I am removing cruft from overly-complicated ebuilds to make them more maintainable. A lot of times, I have completely rewritten or redesigned ebuilds. In these cases, we want to look at the Gentoo ebuild more for ideas and for new patches that we might want to consider, but not be so hasty to apply them. We want to apply them only if they make sense for our plans for the ebuild.

Steps After Ebuilds Are Updated

If you have updated the ebuild to Funtoo standards, and are comfortable that it is ready for inclusion in Funtoo Linux, then follow these steps. If the ebuild is not ready yet, be sure to follow-through and either hand off the ebuild to someone else or check with Daniel to get your questions answered so it can be completed.

General steps to follow once the ebuild is ready for inclusion in Funtoo:

  1. Masking - Mask the ebuild in profiles/package.mask/funtoo-staging - put your masks at the top of the file (reverse chronological order.)
  2. Communicate - Post to the funtoo-dev mailing list and forums announcing the new masked ebuilds, noting that they are available for testing.
  3. Monitor - Monitor community resources for success or failure reports for testing.
  4. If we have sufficient positive replies, and no outstanding issues, move to Funtoo Linux current.
  5. After a period of 2-3 days, move to Funtoo Linux stable.

The List

Important

If you are going to do one of these things, put your name after it so others know :)

Here's a list of ebuilds that need updating:

  • dhcpcd-5.2.11 (or later?) [golodhrim] {already in portage and stable newer versions will follow}
  • gdisk-0.6.14 [angry_vincent] {already in portage for testing} / [404_Error] {Functional on sparc64, not to be used with system disks due to OpenBoot incompatibilities}
  • bash [angry-vincent] {already in portage for testing}
  • tar-1.25+ [angry_vincent] (tar-1.24 had problems with device nodes creation, this is fixed in >=tar-1.25, testing with metro builds) / [404_Error] {Remains to be tested on sparc64}
  • sandbox-2.5 (needs some testing in metro) [angry-vincent/golodhrim] {testing running/golodhrim testing done, working perfect in metro} / [404_Error] {Remains to be tested on sparc64}
  • klibc-1.5.20 (test with uvesafb)
  • dev-lang/perl-5.12.2-r6 [404_error] {already in portage for testing, no issues on sparc64 and amd64 at deployment, perl-cleaner passes, remains to be tested in the long term especially with day to day usage}, -r2 suffers of a parallelism issue

Stuff I (drobbins) can handle:

  • feedparser-5.0.1
  • openvz-sources
  • genkernel {QSG written, some parts to be completed}