The distribution package is a shell archive (example: edrc-1.4.08-200502150919.sh). When you execute the shell archive all needed credentials are prompted and the installation is straight forward.
If you received WA2L/edrc as a splited archive (example: edrc-1.0.00-200401281209.sh.piece_aa ... ax, edrc-1.0.00-200401281209.sh.piece.sh) you have to invoke the edrc-1.0.00-200401281209.sh.piece.sh command first to concatenate the pieces to the shell archive (see step 0 below).
If you received the archive splited into pieces, you have to concatenate the pieces first. A splited archive consists of a setup script and the splited archive: edrc-1.0.00-200401281209.sh.piece.sh (command to concatenate the pieces) edrc-1.0.00-200401281209.sh.piece_ab ... ax (splited archive). The edrc-1.0.00-200401281209.sh.piece.sh takes care that you have all needed pieces available and that those pieces are concatenated correctly.
host-001# sh ./edrc-1.0.00-200401281209.sh.piece.sh
→ goto step 1.
Ensure that you transfer the package in *BINARY* mode to the target system. Many SCP or SFTP clients on Windows (as FileZilla) will transfer this package in ASCII mode if the transfer mode is not explicitly specified as BINARY.
Start FileZilla
-> Connect to server using: SFTP - SSH File Transfer Protocol
-> Set Standard Transfer Type to: Binary
-> Transfer the package file to: host-001:/tmp
→ goto step 2.
Only install the software on the initial system.
In the subsequent steps the installation is configured and repacked. Then the repacked software is installed on all other hosts in the environment.
host-001# sh /tmp/edrc-1.4.08-200502150919.sh
The install script will prompt for all credentials and create the edrc user/group if selected:
***
***
*** SOFTWARE SHELL ARCHIVE
***
*** E D R C - Enterprise Disaster Recovery Console
*** UNIX/Linux version 1.4
*** patchlevel 08
*** developed on Solaris 8, HP-UX 11.00, redhat Linux 7.2/8.0
*** packed Mon Feb 15 09:19:54 MET 2005
***
*** Copyright(C) 2003-2005
*** Christian Walther
***
*** Send comments and bugreports to <wa2l@users.sourceforge.net>
***
***
Installation Logfile ................ : /tmp/edrc-1.4.08-200502150919.sh.1291.log
Only extract .cpio.gz ...... <yn> [n]:
Installation Base Directory ... [/opt]:
Verbose File Extraction .... <yn> [n]:
Create Software User ....... <yn> [n]: y
Username .................... [edrc]:
User-ID ..................... [911]:
Groupname ................... [edrc]:
Group-ID .................... [911]:
Input OK? <ync> [n]: y
Start installation to '/opt/edrc'? <yn> [n]: y
install software package ...
extract software to installation directory ...
252519 blocks
done.
create group ...
Groupname .. : edrc
Group-ID ... : 911
done.
create user ...
Username ... : edrc
User-ID .... : 911
done.
check OSID mapping ...
osid on this system is 'Linux'
done.
post installation steps ...
1) read manpage: /opt/edrc/bin/edrcman edrcsetup
2) read manpage: /opt/edrc/bin/edrcman edrc
3) read manpage: /opt/edrc/bin/edrcman edrcintro
done.
done.
HINTS:
→ goto step 2.2
WA2L/edrc has been developed on HP-UX 11.00 and tested on 11.11 ... 11.31, Solaris 8 ... 10 SPARC and x86, RedHat Linux 7.2, 8.0, Fedora Core 4 ... 17, SuSE Linux 5.3 ... 11.1, Ubuntu 14.04 and has been run on other flavors.
The installation gives the hint in
:
check OSID mapping ...
osid on this system is 'Linux'
done.
:
if the operating system id (OSID) could be resolved.
If the OSID cannot be resolved, the osid command returns unknown:
host-001# ~edrc/lib/osid unknown
The installation of the shell archive will give a hint of the OSID definition, as:
Linux:3.6.11-5.fc17.x86_64:x86_64:unknown:<Comment>:
The unknown placeholder must be replaced by a matching OSID, the <Comment> placeholder should be replaced by a meaningful human readable operating system description.
The OSID definition line can also be resolved later, invoking the ~edrc/lib/osid -e command.
If your Operating System is sufficient similar to:
See also manpages osid(3) and osid.dat(4).
host-001# vi ~edrc/etc/osid.dat.WA2L
1 #
2 # osid.dat.WA2L - operating system map
3 #
4 # [00] ??.??.19?? SFI Initial Version
5 # [01] 31.01.2003 CWa Integrated into EDRC
6 #
:
30 #
31 # Fileformat: (see also man osid.dat)
32 #
33 # <OS>:<release>:<machine>:<OSID>:<Comment>
34 #
35 # <OS> ::= uname -s
36 # <release> ::= uname -r
37 # <machine> ::= uname -m
38 #
:
94 Linux:2.6.18-164.el5:x86_64:Linux:RedHat ELinux Srv 5.4 (Tikanga):
95 Linux:2.6.18-164.el5:ia64:Linux-ia:RedHat ELinux Srv 5.4 (Tikanga):
96 Linux:2.6.35.[0-9][0-9]-[0-9][0-9].fc14.i686:i686:Linux:Fedora Core 14:
97 Linux:3.6.11-5.fc17.x86_64:x86_64:Linux:Fedora Core 17:
~
~
→ goto step 2.3
The shell(1) command provides a proper environment with all needed $PATH and other environment settings and useful additional commands and functions. Invoke usage within the shell to get a quick overview.
host-001# ~edrc/bin/shell [ /root ] [ root@host-001 ][*eshell*/bash]:
→ goto step 3.
If you like to use the distribute command of edrc (highly recommended), the ~edrc/bin/filedist, ~edrc/bin/rcmd commands (very useful) and the ~edrc/bin/passwdsyncd, edit the corresponding security files. It is possible to run the base functionality of WA2L/edrc in a rtools, secure shell or in a mixed setup.
The newer commands ~edrc/bin/rcat, ~edrc/bin/rcomm, ~edrc/bin/rdiff, ~edrc/bin/rosid, ~edrc/bin/ssh-exec, ~edrc/bin/loggrep and ~edrc/bin/whoisin need a secure shell setup.
→ goto step 3.2 (for secure shell connection setup)
→ goto step 3.1 (for rtools connection setup)
→ goto step 3.1 and 3.2 (for a mixed setup)
In nowadays rtools should not be used any more if there is not a really good reason to do so. Instead secure shell as explained in step 3.2. should be used.
→ goto step 3.1.1
[ /root ]
[ root@host-001 ][*eshell*/bash]: vi ~root/.rhosts
1 host-001.acme.net edrc
2 host-002.acme.net edrc
:
:
~
~
→ goto step 3.2 or 4.
Without doupt, this should be the default method to connect to the systems.
→ goto step 3.2.1
This are the "local" ssh keys hat are used to connect within one customer environment.
[ / ]
[ root@host-001 ][*eshell*/bash]: su edrc
[ / ]
[ root@host-001 ][*eshell*/bash]: id
uid=911(edrc) gid=911(edrc) groups=911(edrc)
[ / ]
[ root@host-001 ][*eshell*/bash]: ssh-keygen -t dsa -C edrc@ACME \
-f ~edrc/var/connection/security/edrc/OpenSSH/default/default/id_dsa
[ / ]
[ root@host-001 ][*eshell*/bash]: ssh-keygen -t rsa -C edrc@ACME \
-f ~edrc/var/connection/security/edrc/OpenSSH/default/default/id_rsa
[ / ]
[ root@host-001 ][*eshell*/bash]: exit
See edrc(1m), remote_copy(3) and remote_shell(3) for more information about the edrc/var/connection directory and ssh-keygen(1) for more information about authentication key generation.
If you get the error message "open /opt/edrc/.../default/id_dsa failed: Permission denied" can this be related to SELinux (Security-Enhanced-Linux). To fix this issue without to disable SELinux, invoke:
[ /opt/edrc/var/connection/security/edrc/OpenSSH/default ] [ root@host-001 ][*eshell*/bash]: chcon -t ssh_home_t default
→ goto step 3.2.2
The "global" ssh public keys are those keys that might be used to manage all your customers environments and to connect from your central administration environment.
If you strictly use "local" ssh keys to connect within one customer and the "global" keys to connect from the central admin environment to all your customers and ensure that the private keys *never* leave an environment you can create an easy to manage and secure administration situation where you know all your keys.
In this example ACME is the customer environment and Highlander is the central administration environment (that can consist of a number of Linux/HP-UX/Solaris systems needed to centrally administer all your customers).
[ /root ]
[ root@host-001 ][*eshell*/bash]: vi ~edrc/etc/ssh-keyadd.pub
1 #
2 # ssh-keyadd.pub - global SSH public keys
3 #
4 # [00] 19.09.2010 CWa Initial Version
5 #
6 ssh-dss AATAB3NzaC1kc3MAZACBANTZUzTJIZFxNiZprstBI
sgXgFwk/OrIvRMUlkJIrJRBqITLdxF8sQllWMjhrufv97yd9o
UAnNv0j9YjBYNdT/ZvHn9VadZYZAIoHQ5N+dvX8EbZWLbLtEY
Li49Gwfkf54Tzs0tdle65h4II/LUfE5Z83A3xYpXmB3pkjD1s
4sTvAAAAFTD+03fjToscaJk6dmk1G7RZ7ro8lQAAAIBJcsY8v
iqHK+AcoKTZ+58h8cQAAAIEAoSqZXwjZJfXPJ2Q0eqMbqeTAX
T3oML5byrxw+fnANUvIkc8nlUDmQQUAg3EgmO7cSya1FPXdkp
qefv4vtninFndj8muwsRhzGXgYFwRggvtaV/rtn3VFLWs0MFp
tdk7NZD6/XCpM9JXJCMubIhhFbQ= edrc@Highlander
7 ssh-rsa ATAAB3NzaC1yc2EAAAABIwAAAQEAvkdixAj3Jd9Wf
iuTSuxYqaTZT0/xXePHeuBltwIV1LV6oQNRRU8wz6EnzqLYqC
l2qeOTTFBVZVJUvQ55ohDhLQ/7SKLF7B1na4JYAONnqLpR/A+
cFTI9jQrPHudEhPwS80xx65jSCBOMq+ydZtFLLFnd+HiX/5rz
K86QXC7HCcnfXezr+78jcpBgWDpQ== edrc@Highlander
~
~
See ssh-keyadd.pub(4) for more information about this configuration file.
→ goto step 3.2.3
The command ssh-keyadd allows to efficiently handle the different ssh keys and also to quickly check the applied keys:
[ /root ]
[ root@host-001 ][*eshell*/bash]: ssh-keyadd
ssh-keyadd - add SSH public keys to a user, by Chr. Walther
add public keys to user 'root' ...
list user's public SSH keys ...
TYPE KEY COMMENT
---- --- -------
(0)
done.
list of global keys to add ...
TYPE KEY COMMENT
------- ------------------------------------ ---------------
ssh-dss AATAB3NzaC1kc3MA...pM9JXJCMubIhhFbQ= edrc@Highlander
ssh-rsa ATAAB3NzaC1yc2EA...ezr+78jcpBgWDpQ== edrc@Highlander
(2)
done.
add global keys? <yn> [y] :
list of local keys to add ...
TYPE KEY COMMENT
------- ------------------------------------ ---------
ssh-dss AAAAB3NzaC1kc3MA...Q/oCZennu8x67FA== edrc@ACME
ssh-rsa AAAAB3NzaC1yc2EA...rk+O/5IuBE4mmgpJl edrc@ACME
(2)
done.
add local keys? <yn> [y] :
add keys ...
edit authfile '/root/.ssh/authorized_keys' ...(global)...(local)... done.
done.
list user's public SSH keys ...
TYPE KEY COMMENT
------- ------------------------------------ ---------------
ssh-dss AAAAB3NzaC1kc3MA...Q/oCZennu8x67FA== edrc@ACME
ssh-rsa AAAAB3NzaC1yc2EA...rk+O/5IuBE4mmgpJl edrc@ACME
ssh-dss AATAB3NzaC1kc3MA...pM9JXJCMubIhhFbQ= edrc@Highlander
ssh-rsa ATAAB3NzaC1yc2EA...ezr+78jcpBgWDpQ== edrc@Highlander
(4)
done.
adjust SSH daemon configuration? <yn> [y] :
adjust SSH daemon configuration ...
edit configfile '/etc/ssh/sshd_config' ... done.
done.
send HUP signal to SSH daemon? <yn> [y] :
send HUP signal to SSH daemon ...
process '/usr/sbin/sshd' with PID '9268' ... done.
done.
done.
See ssh-keyadd(1m) for more information about the command.
→ goto step 4.
With
edrcman
you can read the system and WA2L/edrc manpages without the need
of adjusting the
$MANPATH
variable.
If
shell
or
edrc
is started, the
man
command is an alias to
edrcman.
[ /root ] [ root@host-001 ][*eshell*/bash]: edrcman EDRC [ /root ] [ root@host-001 ][*eshell*/bash]: edrcman edrcintro [ /root ] [ root@host-001 ][*eshell*/bash]: edrcman edrc
→ goto step 5.
Change to the configuration directory of WA2L/edrc.
[ /root ] [ root@host-001 ][*eshell*/bash]: cdetc
→ goto step 5.1.1
In the server_environment.cfg it is defined which customer and environment (e.g. Customer=ACME, Environment=DEVELOPMENT) is related to certain servers.
[ /opt/edrc/etc ]
[ root@host-001 ][*eshell*/bash]: vi server_environment.cfg
1 #
2 # server_environment.cfg - config for server_environment
3 #
4 # [00] 24.07.2004 CWa Initial Version
5 #
6
7 # Server environment definition.
8 #
9 # If you log on to a system, the <NAME> field of the
10 # first matching <server_regex> will be returned.
11 #
:
15 #
16 # Format:
17 # <NAME>:<Description>:<server_regex>:<Customer>:
18 #
:
25 # ACME
26 #
27 PRODUCTION:Datacenter Bern, PRODUCTION Env:host-3[0-9][0-9]:ACME:
28 PREPRODUCTION:Datacenter Boston, Integration Env:host-2[0-9][0-9]:ACME:
29 TEST:Datacenter Plano, Test Env:host-1[0-9][0-9]:ACME:
30 DEVELOPMENT:Datacenter San Jose, Development Env:host-0[0-9][0-9]:ACME:
31
~
~
→ goto step 5.1.2
The hosts listed in the
hostlist.dat
file are returned when the
hostlist
[
options
]
command is used.
This enables you to
write scripts that dynamically only address the hosts that
are located in the same environment (e.g. TEST) as where
you are starting the script. In other environments
(e.g. PRODUCTION) the identical script can be used without
modifications, but it will automatically address the hosts
in that environment. With this method your script does not
need to know about the actual setup of the environment.
Furthermore, to address a certain set of hosts, hostgroups can be defined.
The @_DIST hostgroup is "private" and is used to define the targets where the recovery script tree is distributed when invoking the distribute command in edrc. The @_DIST hostgroup should not be used in scripts.
The @ALL hostgroup is to address all hosts that exist in all environments of a customer setup (e.g. DEVELOPMENT + TEST + PREPRODUCTION + PRODUCTION). This hostgroup can be used in scripts.
In the following example the @APP hostgroup is used to address all application servers. The @DB hostgroup contains all database servers in the environment.
Set the USE_HOSTLIST_DAT setting in the hostlist.cfg file to True as in the given example:
[ /opt/edrc/etc ]
[ root@host-001 ][*eshell*/bash]: vi hostlist.cfg
1 #
2 # etc/hostlist.cfg - configuration of hostlist
3 #
4 # [00] 16.02.2004 CWa Initial Version
5 #
6
7 # Set USE_HOSTLIST_DAT to True, if hosts are listed in
8 # the etc/hostlist.dat file, if hosts are defined directly
9 # in etc/hostlist.cfg, set USE_HOSTLIST_DAT to False.
10 #
11 USE_HOSTLIST_DAT=True
:
~
~
and add the hosts in the hostlist.dat file as in the following example:
[ /opt/edrc/etc ]
[ root@host-001 ][*eshell*/bash]: vi hostlist.dat
1 #
2 # etc/hostlist.dat - hostlist csv database file
3 #
4 # [00] 12.08.2008 CWa Initial Version
5 # [58] 16.03.2013 CWa chg: to hostlistdat2cfg structure
6 #
7
8 #
9 # Format:
10 #
11 # <CUSTOMER>;<ENVIRONMENT>;<GROUPS>;<OPTIONS>;<HOSTS>
12 #
13 # To verify the syntax, use: hostlistdat2cfg -a list_dat
14 # Only correct entries will be listed.
15 #
16 ACME ;DEVELOPMENT ;@APP ;;host-001 host-002;
17 ACME ;DEVELOPMENT ;@DB ;;host-003;
18 ACME ;TEST ; ;;host-101 host-103;
19 ACME ;PREPRODUCTION ; ;;host-201 host-203 host-205;
20 ACME ;PRODUCTION ; ;;host-303 host-308 host-309;
~
~
The @_DIST and @ALL host groups don't have to be defined. The hostlistdat2cfg command, that is used to generate the hostlist configuration, creates those groups automatically.
If the setting CMAN_ENVIRONMENT=CUSTOMER.NAME in hostlist.cfg is used, more groups are available automatically when calling the hostlist command on a host that is part of the environment that is defined as the central administration environment.
To verify your settings use
[ /opt/edrc/etc ] [ root@host-001 ][*eshell*/bash]: hostlist -p
to print all available hostgroups (human readable) and
[ /opt/edrc/etc ] [ root@host-001 ][*eshell*/bash]: server_environment -l
to list all defined server environments.
See server_environment(3), server_environment.cfg(4), hostlist(3), hostlist.cfg(4), hostlistdat2cfg(3) and hostlist.dat(4) for more information. Configuration file samples are available in the edrc/var/samples/hostlist/ directory.
If you installed WA2L/edrc as user root and used the edrc user to point to the software, as suggested in step 2.1, the main functions of the WA2L/edrc package are configured now.
→ goto step 5.2
Now all other configuration files of WA2L/edrc can be checked and adjusted.
The general concept of the configurations in WA2L/edrc is, that
the configuration files can be kept identical on all hosts
across environments and customers.
To achieve this, the
server_environment(3)
and
hostlist(3)
commands are used extensively to set configuration values
dynamically whenever possible.
[ /root ] [ root@host-001 ][*eshell*/bash]: cdetc [ /opt/edrc/etc ] [ root@host-001 ][*eshell*/bash]: vi *.cfg
This step can also be performed later. The files then can be edited on one host and distributed to the others easily using the filedist(1) command.
→ goto step 5.3
If disk space consumption is of concern the contents of the directories edrc/src/ and edrc/man/OS/ can be removed without impact to the running WA2L/edrc installation.
[ /opt/edrc ] [ root@host-001 ][*eshell*/bash]: rm -rf man/OS/* [ /opt/edrc ] [ root@host-001 ][*eshell*/bash]: rm -rf src/*
→ goto step 6
Now, when the configuration is done, the software is repacked. This will supersede the configuration effort on the other systems within the customer environments.
[ /opt/edrc ]
[ root@host-001 ][*eshell*/bash]: pack
pack - create application package, by Chr. Walther
create package of application in '/opt/edrc' ...
application information ...
APPLICATION .......... : default
APPLICATION_PREFIX ... : edrc_ACME
APPLICATION_NAME ..... : WA2L/edrc
APPLICATION_RELEASE .. : 1.4.08
DESCRIPTION .......... : WA2L/edrc complete
done.
package information ...
format ............... : shar
type ................. : RELEASE
file ................. : host-001:/tmp/edrc_ACME-1.4.08-200504012315.sh
done.
write sadm file ...(/opt/edrc/var/pack/sadm/edrc_ACME-1.4.08-200504012315.gz)... done.
evaluate files to be packed ...(15137 files)... done.
evaluate properties of files to be packed ... done.
pack files to package file ...(258374 kB)... done.
done.
→ goto step 6.2
Copy the created package to all environments of one customer.
[ /opt/edrc ]
[ root@host-001 ][*eshell*/bash]: scp \
/tmp/edrc_ACME-1.4.08-200504012315.sh root@host-002:/tmp
[ /opt/edrc ]
[ root@host-001 ][*eshell*/bash]: scp \
/tmp/edrc_ACME-1.4.08-200504012315.sh root@host-003:/tmp
:
:
→ goto step 6.3
Initially this is a manual task.
Later the
filedist(1)
and
rcmd(1)
commands can be used to roll-out files and to execute commands
easily on many systems.
For common software handling tasks, as patching, package
generation etc. a special "recovery" script tree provided
thru the
sys(1m)
short start, can be used.
host-002# sh /tmp/edrc_ACME-1.4.08-200504012315.sh host-002# ~edrc/bin/ssh-keyadd -y host-003# sh /tmp/edrc_ACME-1.4.08-200504012315.sh host-003# ~edrc/bin/ssh-keyadd -y : :
→ goto step 7
The "EDRC - Enterprise Disaster Recovery Console" startup command is ~edrc/sbin/edrc. The short starts ~edrc/bin/sat, ~edrc/bin/asup, ~edrc/bin/psup and ~edrc/bin/osup give access to special purpose "recovery" script trees, as system- or application administration tasks.
From now on you can also use the filedist(1) command to easily distribute files and rcmd(1) to execute command(s) on all hosts in the environment.
To distribute recovery script trees in edrc(1m), sat(1m) etc., the distribute command in edrc can be used.
Patches of the application can be downloaded from http://sourceforge.net/projects/wa2l-edrc/ or your repository server and installed using the edrcupgrade command in edrc.
Currently the following pre-configured "recovery" script trees are distributed with WA2L/edrc:
Disaster recovery script tree.
System configuration handling and some automated EDRC tasks as
WA2L/edrc roll-out and WA2L/edrc patch installation.
This menu tree is considered to be part of the WA2L/edrc package
and is patched, too. Therefore you should not add/remove/change
files in this "recovery" script tree, due to the fact that your
changes might be lost after an WA2L/edrc update.
Menu tree to efficiently handle lots(1m), (long term data save).
This menu is also considered to be part of the WA2L/edrc package and is patched, too. The config files lotsctl.cfg(4), edrc.lotsctl.cfg and the topmost _env file in the menu tree will not be overwritten by patches and are allowed to be changed.
If adjusting the mentioned configuration files is not sufficient for your needs and you like to adjust the menu tree provided thru lotsctl, consider to create a copy of it using edrc/scripts/lotsctl as template when invoking the newscripttree contributed edrc command and adjusting the SCRIPTS_BASEDIR setting in edrc/etc/edrc.lotsctl.cfg to point to the created copy.
System Administration menus to automate common tasks in the environment.
System Administration menu for application support tasks in the environment. Please pay attention to the special configuration for this menu tree, which is part of the ~edrc/bin/sat tree, but editing and distribution is denied because the idea is to start it by non-root users via sudo.
System Administration menu for production support tasks in the environment. Please pay attention to the special configuration for this menu tree, which is part of the ~edrc/bin/sat tree, but editing and distribution is denied because the idea is to start it by non-root users via sudo.
System Administration menus for operation support tasks in the environment. Please pay attention to the special configuration for this menu tree, which is part of the ~edrc/bin/sat tree, but editing and distribution is denied.
To start some commands thru sudo, the following lines could be added to the /etc/sudoers file, using the visudo command. To ensure, that the user has to supply the own password to execute the privileged commands, the settings in line 55 and 56 should be commented out or removed from the file.
In the example below the PASSWD: setting results in asking for the password of the calling (unprivileged) user prior to command execution as an additional security measurement.
[ /etc ]
[ root@host-001 ][*eshell*/bash]: sav sudoers; visudo
1 #
2 # /etc/sudoers - sudo access definition file
3 #
4 # [01] 25.02.2012 CWa +*_EDRC_* definitions
5 #
6 ##
7 ## Sudoers allows particular users to run various commands
8 ## as the root user, without needing the root password.
9 ##
:
18 ## User Aliases
19 User_Alias ROLE_EDRC_ADM = john, fred
20 User_Alias ROLE_EDRC_OPS = barney
21 User_Alias ROLE_EDRC_USR = wilma, betty
22
23 # WA2L/edrc definitions
24 #
25 ROLE_EDRC_ADM ALL = PASSWD: CMD_EDRC_USR, CMD_EDRC_OPS, CMD_EDRC_ADM
26 ROLE_EDRC_OPS ALL = PASSWD: CMD_EDRC_USR, CMD_EDRC_OPS
27 ROLE_EDRC_USR ALL = PASSWD: CMD_EDRC_USR
28 Cmnd_Alias CMD_EDRC_ADM = /opt/edrc/bin/shell, /opt/edrc/bin/sat,\
29 /opt/edrc/sbin/edrc, /opt/edrc/bin/sys
30 Cmnd_Alias CMD_EDRC_OPS = /opt/edrc/bin/osup, /opt/edrc/bin/lotsctl
31 Cmnd_Alias CMD_EDRC_USR = /opt/edrc/bin/asup, /opt/edrc/bin/psup
:
51 # In the default (unconfigured) configuration, sudo asks for the root
52 # password. This allows use of an ordinary user account for
53 # administration of a fresh installed system. When configuring sudo,
54 # delete the two following lines:
55 #Defaults targetpw # specify passwd of target user i.e root
56 #ALL ALL=(ALL) ALL # only together with 'Defaults targetpw'
:
~
~
~
See also pf_wrapper(1) for a more detailed description of the sudoers example above.
As soon as the sudoers entries are defined as given above, the commands asup, edrc, lotsctl, osup, psup, sat, shell and sys can be started by the user being member of the related role with root permissions simply by adding the directory ~edrc/pbin to the $PATH environment variable ( export PATH=~edrc/pbin:$PATH ) in the related personal shell startup rc-file. This also works, if RBAC for controlling elevated permissions is used.
Therefore when using the pbin directory, a user having elevated permissions on those commands does not need to know, if it is needed to use sudo sat or pfexec sat on a certain system, it is sufficient to call sat.
See section FILES in edrcintro(1) for a description of the pbin directory and pf_wrapper(1).
This is free software; see edrc/doc/COPYING for copying conditions. There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.