From Fedora Project Wiki
(First Version of the System Configuration Shell Feature Description)
 
(Moved to FeatureReadyForFesco for approval (#988))
 
(11 intermediate revisions by 2 users not shown)
Line 6: Line 6:
== Owner ==
== Owner ==
* Name: [[User:tschwaller| Tom Schwaller]]
* Name: [[User:tschwaller| Tom Schwaller]]
* Email: tom.schwaller@web.de
* Email: tom dot schwaller at web dot de


== Current status ==
== Current status ==
Line 15: Line 15:
== Detailed Description ==
== Detailed Description ==


Network Administrators love their very powerful Switch/Router/Firewall/etc. CLI which can be used for all administrative tasks in a very structured and well documented way. Compare that to classical Linux System Administration which is a mix of editing configuration files using very different formats and executing commands & scripts with a heterogeneous syntax. The System Configuration Shell will provide an interactive command line interface using the [https://github.com/agrover/configshell-fb python-configshell] framework with a standardized syntax to manage your system. It consists of the command <code>configsh</code> which starts an interactive shell and can also be used in shell scripts and the command <code>config</code> for one-shot configuration commands (e.g. <code>config hostname www.fedoraproject.org</code> which not only executes <code>hostname www.fedoraproject.org</code> but also changes some configuration files to make the new hostname permanent).  
Network Administrators love their very powerful switch/router/firewall/etc. CLI which can be used for all administrative tasks in a very structured and well documented way. Compare that to classical Linux System Administration which is a mix of editing configuration files using different formats and executing commands & scripts with a heterogeneous syntax. The System Configuration Shell will provide an interactive command line interface using the [https://github.com/agrover/configshell-fb python-configshell] framework with a standardized syntax to manage your system. It consists of the command <code>configsh</code> which starts an interactive shell and can also be used in shell scripts and the command <code>config</code> for one-shot configuration commands (e.g. <code>config hostname www.fedoraproject.org</code> which not only executes <code>hostname www.fedoraproject.org</code> but also changes several configuration files to make the new hostname permanent).  


The System Configuration Shell should enable Linux System administrators to do their standard tasks more easily. Since every command will be logged (in a verbose mode even showing the exact system commands and scripts executed), each administrator can decide him/herself if he/she feels comfortable using parts of (or exending) the System Configuration Shell. The approach is similar to the OpenWrt [http://wiki.openwrt.org/doc/uci#command.line.utility UCI Command Line Utility] or the Vyatta [http://wiki.het.net/wiki/CLI_internals vbash] but using a mixed hierarchical/flat namespace.
The System Configuration Shell will facilitate the Linux System administrators daily work. Since every command is logged (in a verbose mode even showing the exact system commands and scripts executed), each administrator can decide him/herself if he/she feels comfortable using standard parts (or local extensions) the System Configuration Shell. The approach is similar to the OpenWrt [http://wiki.openwrt.org/doc/uci#command.line.utility UCI Command Line Utility] or the Vyatta [http://wiki.het.net/wiki/CLI_internals vbash] but using a different approach.


To get an idea how a <code>python-configshell</code> based approach looks like watch Andy Grovers
To get an idea how a <code>python-configshell</code> based CLI looks like watch Andy Grovers
[http://www.youtube.com/watch?v=BkBGTBadOO8 targetcli screencast series]. The following very simple and incomplete [http://tomsreadme.wordpress.com/2013/01/08/example-shell/ example-shell] uses <code>libuser, hdparm</code> and some well known system commands to change e.g. user entries. The same commands (<code>ls/change</code>) could also get a Kerberos ticket and do a <code>ldapsearch/ldapmodify</code> showing the power of this approach.
[http://www.youtube.com/watch?v=BkBGTBadOO8 targetcli screencast series]. The following very simple and incomplete [https://fedorahosted.org/fesco/attachment/ticket/988/exampleshell example-shell] uses <code>libuser, hdparm</code> and some well known system commands to change e.g. user entries and show disk properties. The same <code>ls/change</code> commands could also get a Kerberos ticket and execute <code>ldapsearch/ldapmodify</code> commands showing the power of this approach.


<pre>
<pre>
# configsh
# configsh


> cd /system/users
> cd /system/users (use TAB completion!)
> show
> show
...
...
Line 79: Line 79:
* The System Configuration Shell also represents a single point of information without forcing users to use multiple tools.
* The System Configuration Shell also represents a single point of information without forcing users to use multiple tools.
* Basic configuration changes can be done with standardized commands while experienced administrators can still tweak their systems by other means or even integrate their own scripts into the System Configuration Shell.
* Basic configuration changes can be done with standardized commands while experienced administrators can still tweak their systems by other means or even integrate their own scripts into the System Configuration Shell.
* Higher level configuration tools like Puppet, Chef, Juju, etc. can use the same underlying configuration comands.
* Higher level configuration tools like Puppet, Chef, Juju, etc. can use the same underlying configuration commands.
* Education material for new users can use standardized commands with a homogeneous syntax instead of mixing configuration file changes and CLI tools (similar to documentation for Switches, Routers and other embedded devices).
* Education material for new Fedora users can use standardized commands with a homogeneous syntax instead of mixing configuration file changes and CLI tools (similar to documentation for switches, routers, firewall and other embedded devices).
* Many hand written CLIs (e.g. virsh, smartctl), setup tools (e.g. ipa-server-install), test scripts could be replaced by System Configuration Shell modules


== Scope ==
== Scope ==


The basic work (i.e. <code>python-configshell</code>) for the System Configuration Shell has already been done according to a design described in a paper about [http://tomsreadme.wordpress.com/2009/07/31/a-smarter-cli/ a smarter CLI] and is also beeing used in the <code>targetcli</code>. The next step consists of writing some Python meta classes to minimize repetitive coding of shell wrappers and define the first objects in the configuration hierarchy. The [http://wiki.openwrt.org/doc/uci#command.line.utility Unified Configuration Interface (UCI) Command Line Utility] of the [https://openwrt.org OpenWrt project], the Vyatta vBash (check e.g.  the [http://www.vyatta.com/downloads/documentation/VC6.5/Vyatta-QuickStart_6.5R1_v01.pdf Vyatta Quick Start Guide], [http://augeas.net Augeas] and any commercial Switch/Router CLI are good starting points for networking related objects.
The basic work (i.e. <code>python-configshell</code>) for the System Configuration Shell has already been done according to a design described in the [http://tomsreadme.wordpress.com/2009/07/31/a-smarter-cli/ smarter CLI] paper and is also beeing used in the <code>targetcli</code>. The next step consists of writing some Python meta classes to minimize repetitive coding of shell wrappers, define simple uses cases and implement initial objects in the configuration hierarchy. The [http://wiki.openwrt.org/doc/uci#command.line.utility Unified Configuration Interface (UCI) Command Line Utility] of the [https://openwrt.org OpenWrt project], the Vyatta vBash (check e.g.  the [http://www.vyatta.com/downloads/documentation/VC6.5/Vyatta-QuickStart_6.5R1_v01.pdf Vyatta Quick Start Guide]), [http://augeas.net Augeas] and any commercial switch/router/firewall CLI are good starting points for networking related objects.


A simple configuration shell example using <code>python-configshell, libuser</code> and <code>hdparm</code> can be found [http://tomsreadme.wordpress.com/2013/01/08/example-shell/ here].  
A simple configuration shell example using <code>python-configshell, libuser</code> and <code>hdparm</code> can be found [https://fedorahosted.org/fesco/attachment/ticket/988/exampleshell here].  


The System Configuration Shell does not affect other parts of the distribution since it is just wrapper code. The different modules of the System Configuration Shell can be loaded on demand (e.g. <code>import user</code>) and configured according to the administrators preference (using <code>~/.configsh/configshrc, /etc/configshrc</code> or CLI commands using these configuration files). The scope of this feature will be extended step by step:
The System Configuration Shell does not affect other parts of the distribution since it is just wrapper code. The different modules of the System Configuration Shell can be loaded on demand (e.g. <code>import user</code>) and configured according to the administrators preference (using <code>~/.configsh/configshrc, /etc/configshrc</code> or CLI commands implicitely using these configuration files). The scope of this feature will be extended step by step and should start with very useful but simple commands (e.g. setting hostnames permanently, defining bonds whithout editing <code>/etc/sysconfig/network-scripts/ifcfg-*</code> scripts, etc.):


* User/Group management (<code>system/users, /system/groups</code>)
* User/Group/Password/SSH Key management (<code>system/users, /system/groups</code>)
* Hardware related information (<code>/system/hardware/</code> using <code>lspci, lsusb, lsscsi</code>, etc. )
* Hardware related information (<code>/system/hardware/</code> using <code>lspci, lsusb, lsscsi</code>, etc. )
* Storage management using [[Features/SystemStorageManager|System Storage Manager]] and [[Features/StorageManagement|targetd]]
* Storage management using [[Features/SystemStorageManager|System Storage Manager]] and [[Features/StorageManagement|targetd]]
* Simple Network related configuration (hostname, IP adresses, routing, bonding, VLANs, traffic shaping, bridges/openvswitch, DCBX, IEEE 802.1Qbg, ARP tables, etc.)
* Simple Network related configuration (hostname, IP adresses, routing, bonds, VLANs, traffic shaping, bridges/openvswitch, DCBX, IEEE 802.1Qbg, ARP tables, etc.)
* Network services (NTP, LLDP, DHCP, DNS, SNMP, SSH, FTP, TFTP, FreeIPA, HTTP, etc.)
* Network services (NTP, LLDP, DHCP, DNS, SNMP, SSH, FTP, TFTP, FreeIPA, HTTP, etc.)
* System services in general using [https://fedoraproject.org/wiki/Features/systemd systemctl] (<code>/system/services</code>)
* System services in general using [https://fedoraproject.org/wiki/Features/systemd systemctl] (<code>/system/services</code>)
* Package management using yum and other RPM tools (<code>/system/software</code>)
* Package management using yum and other RPM tools (<code>/system/software</code>)
* Printing (printers, printing jobs, etc,) using CUPS and SNMP-based tools
* Print management (printers, print jobs, etc,) using CUPS, lp* and SNMP-based tools
* Virtualization management (using a user friendly wrapper around <code>libvirt</code> potentially replacing <code>virsh</code>)
* Virtualization management (using a user friendly wrapper around <code>libvirt</code> potentially replacing <code>virsh</code>)
* Cloud Management (e.g. a user friendly wrapper around OpenStack CLI tools)
* Cloud management (e.g. a user friendly wrapper around OpenStack CLI tools)
* Application Management
* Application management
* Backup/Restore Management
* Backup/Restore management
* and much more...
* and much more...


In the initial versions the subsystems will be separated to a great extent, but the real value of the System Configuration Shell will become clearer by integrating different subsystems in a transparent fashion using userfriendly and interactive domain specific languages.
In the initial versions the different submodules will work separately, but the real value of the System Configuration Shell will become clearer by integrating several subsystems in a transparent fashion using user friendly and interactive domain specific languages.


== How To Test ==
== How To Test ==
Line 115: Line 116:
* Different tools will be integrated into a single place with a similar CLI syntax.  
* Different tools will be integrated into a single place with a similar CLI syntax.  
* Familier commands like <code>ls, get, set</code> and <code>show</code> used in different contexts will be much more powerful than in the past (a simple <code>ls</code> could show the result of an LDAP search against a FreeIPA server!)
* Familier commands like <code>ls, get, set</code> and <code>show</code> used in different contexts will be much more powerful than in the past (a simple <code>ls</code> could show the result of an LDAP search against a FreeIPA server!)
* The Configuration objects are structured in a hierarchical fassion but are also accessible globably if this is appropriate (e.g. <code>show pci</code> instead of <code>cd /system/hardware/pci; show</code>)
* The Configuration objects are structured in a hierarchical fassion but are also accessible globably if this is appropriate (e.g. <code>show pci</code> and also <code>cd /system/hardware/pci; show</code>)
* Administrators can integrate their own scripts into the System Configuration Shell and make it even more powerful.
* Administrators can integrate their own scripts into the System Configuration Shell and make it even more powerful.


Line 129: Line 130:


* Each CLI command must include a <code>__doc__</code> string which documents it's usage including all subcommands, parameters, etc.
* Each CLI command must include a <code>__doc__</code> string which documents it's usage including all subcommands, parameters, etc.
* The general philosophy behind the System Configuration Shell is documented in the paper [http://tomsreadme.wordpress.com/2009/07/31/a-smarter-cli/ a smarter CLI].  
* The general philosophy behind the System Configuration Shell is documented in the [http://tomsreadme.wordpress.com/2009/07/31/a-smarter-cli/ smarter CLI] paper.  
* A best practice document will be produced when the shell has sufficiently rich semantics.
* A best practice document needs to be produced when the shell has sufficiently rich semantics.


== Release Notes ==
== Release Notes ==
Line 140: Line 141:
* See [[Talk:Features/SystemConfigurationShell]]
* See [[Talk:Features/SystemConfigurationShell]]


[[Category:FeatureReadyForWrangler]]
[[Category:FeatureReadyForFesco]]
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->

Latest revision as of 15:56, 12 February 2013

System Configuration Shell

Summary

The System Configuration Shell System provides an easy to use interactive command line interface with a standardized syntax to manage your system.

Owner

Current status

  • Targeted release: Fedora 19
  • Last updated: 2013-01-08
  • Percentage of completion: 00%

Detailed Description

Network Administrators love their very powerful switch/router/firewall/etc. CLI which can be used for all administrative tasks in a very structured and well documented way. Compare that to classical Linux System Administration which is a mix of editing configuration files using different formats and executing commands & scripts with a heterogeneous syntax. The System Configuration Shell will provide an interactive command line interface using the python-configshell framework with a standardized syntax to manage your system. It consists of the command configsh which starts an interactive shell and can also be used in shell scripts and the command config for one-shot configuration commands (e.g. config hostname www.fedoraproject.org which not only executes hostname www.fedoraproject.org but also changes several configuration files to make the new hostname permanent).

The System Configuration Shell will facilitate the Linux System administrators daily work. Since every command is logged (in a verbose mode even showing the exact system commands and scripts executed), each administrator can decide him/herself if he/she feels comfortable using standard parts (or local extensions) the System Configuration Shell. The approach is similar to the OpenWrt UCI Command Line Utility or the Vyatta vbash but using a different approach.

To get an idea how a python-configshell based CLI looks like watch Andy Grovers targetcli screencast series. The following very simple and incomplete example-shell uses libuser, hdparm and some well known system commands to change e.g. user entries and show disk properties. The same ls/change commands could also get a Kerberos ticket and execute ldapsearch/ldapmodify commands showing the power of this approach.

# configsh

> cd /system/users (use TAB completion!)
> show
...
quantum:x:164:164:OpenStack Quantum Daemons:/var/lib/quantum:/sbin/nologin
avahi:x:70:70:Avahi mDNS/DNS-SD Stack:/var/run/avahi-daemon:/sbin/nologin
memcached:x:992:990:Memcached daemon:/run/memcached:/sbin/nologin
mysql:x:27:27:MySQL Server:/var/lib/mysql:/bin/bash
openvpn:x:991:989:OpenVPN:/etc/openvpn:/sbin/nologin
lightdm:x:990:988::/var/log/lightdm:/sbin/nologin
mailnull:x:47:47::/var/spool/mqueue:/sbin/nologin
smmsp:x:51:51::/var/spool/mqueue:/sbin/nologin

/system/users> cd tom (use TAB completion!)
/system/users/tom> change shell=/bin/bash home=/home/tom (overloading "set" seems more natural!)

> cd /system/hardware/partitions/sda (use TAB completion!)
/system/hardware/partitions/sda> ls  (uses hdparm)

/dev/sda:
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00
                                      00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

ATA device, with non-removable media
Standards:
        Likely used: 1
Configuration:
        Logical         max     current
        cylinders       0       0
        heads           0       0
        sectors/track   0       0
        --
        Logical/Physical Sector size:           512 bytes
        device size with M = 1024*1024:           0 MBytes
        device size with M = 1000*1000:           0 MBytes
        cache/buffer size  = unknown
Capabilities:
        IORDY not likely
        Cannot perform double-word IO
        R/W multiple sector transfer: not supported
        DMA: not supported
        PIO: pio0

/system/hardware/partitions/sda> benchmark  (also uses hdparm)

/dev/sda:
 Timing buffered disk reads: 1594 MB in  3.00 seconds = 638.11 MB/sec

Benefit to Fedora

  • Fedora will have a better, more user friendly interactive system management utility.
  • The System Configuration Shell also represents a single point of information without forcing users to use multiple tools.
  • Basic configuration changes can be done with standardized commands while experienced administrators can still tweak their systems by other means or even integrate their own scripts into the System Configuration Shell.
  • Higher level configuration tools like Puppet, Chef, Juju, etc. can use the same underlying configuration commands.
  • Education material for new Fedora users can use standardized commands with a homogeneous syntax instead of mixing configuration file changes and CLI tools (similar to documentation for switches, routers, firewall and other embedded devices).
  • Many hand written CLIs (e.g. virsh, smartctl), setup tools (e.g. ipa-server-install), test scripts could be replaced by System Configuration Shell modules

Scope

The basic work (i.e. python-configshell) for the System Configuration Shell has already been done according to a design described in the smarter CLI paper and is also beeing used in the targetcli. The next step consists of writing some Python meta classes to minimize repetitive coding of shell wrappers, define simple uses cases and implement initial objects in the configuration hierarchy. The Unified Configuration Interface (UCI) Command Line Utility of the OpenWrt project, the Vyatta vBash (check e.g. the Vyatta Quick Start Guide), Augeas and any commercial switch/router/firewall CLI are good starting points for networking related objects.

A simple configuration shell example using python-configshell, libuser and hdparm can be found here.

The System Configuration Shell does not affect other parts of the distribution since it is just wrapper code. The different modules of the System Configuration Shell can be loaded on demand (e.g. import user) and configured according to the administrators preference (using ~/.configsh/configshrc, /etc/configshrc or CLI commands implicitely using these configuration files). The scope of this feature will be extended step by step and should start with very useful but simple commands (e.g. setting hostnames permanently, defining bonds whithout editing /etc/sysconfig/network-scripts/ifcfg-* scripts, etc.):

  • User/Group/Password/SSH Key management (system/users, /system/groups)
  • Hardware related information (/system/hardware/ using lspci, lsusb, lsscsi, etc. )
  • Storage management using System Storage Manager and targetd
  • Simple Network related configuration (hostname, IP adresses, routing, bonds, VLANs, traffic shaping, bridges/openvswitch, DCBX, IEEE 802.1Qbg, ARP tables, etc.)
  • Network services (NTP, LLDP, DHCP, DNS, SNMP, SSH, FTP, TFTP, FreeIPA, HTTP, etc.)
  • System services in general using systemctl (/system/services)
  • Package management using yum and other RPM tools (/system/software)
  • Print management (printers, print jobs, etc,) using CUPS, lp* and SNMP-based tools
  • Virtualization management (using a user friendly wrapper around libvirt potentially replacing virsh)
  • Cloud management (e.g. a user friendly wrapper around OpenStack CLI tools)
  • Application management
  • Backup/Restore management
  • and much more...

In the initial versions the different submodules will work separately, but the real value of the System Configuration Shell will become clearer by integrating several subsystems in a transparent fashion using user friendly and interactive domain specific languages.

How To Test

A detailed test plan depends on the modules beeing implemented in the System Configuration Shell and will be worked out accordingly. Each CLI command needs to implement a test case and if possible a rollback (undo) command so testing can be easily automated. Many other Fedora test plans could use extensions of the System Configuration Shell for testing.

User Experience

  • Administrators and users will be able to manage their Fedora systems more easily and reliably with the System Configuration Shell.
  • Different tools will be integrated into a single place with a similar CLI syntax.
  • Familier commands like ls, get, set and show used in different contexts will be much more powerful than in the past (a simple ls could show the result of an LDAP search against a FreeIPA server!)
  • The Configuration objects are structured in a hierarchical fassion but are also accessible globably if this is appropriate (e.g. show pci and also cd /system/hardware/pci; show)
  • Administrators can integrate their own scripts into the System Configuration Shell and make it even more powerful.

Dependencies

The core package depends on python-configshell, the different submodules on the subsystems they are a wrapping.

Contingency Plan

No plan needed. If this feature is not ready, it can simply be dropped.

Documentation

  • Each CLI command must include a __doc__ string which documents it's usage including all subcommands, parameters, etc.
  • The general philosophy behind the System Configuration Shell is documented in the smarter CLI paper.
  • A best practice document needs to be produced when the shell has sufficiently rich semantics.

Release Notes

  • Fedora 19 includes the first version of the System Configuration Shell which provides an easy to use interactive command line interface to manage your system.

Comments and Discussion