IntenseWebs/freeipa
3
0
Fork 0
mirror of https://salsa.debian.org/freeipa-team/freeipa.git synced 2025-01-02 12:16:56 -06:00
Code Issues Packages Projects Releases Wiki Activity
fca0f4dd65
freeipa/VERSION

83 lines
4.0 KiB
Plaintext
Raw Normal View History

Redo the way versioning works in freeIPA. The file VERSION is now the sole-source of versioning. The generated .spec files will been removed in the maintainer-clean targets and have been removed from the repository. By default a GIT build is done. To do a non-GIT build do: $ make TARGET IPA_VERSION_IS_GIT_SNAPSHOT=no When updating the version you can run this to regenerate the version: $ make version-update The version can be determined in Python by using ipaserver.version.VERSION
2008-04-30 16:49:52 -05:00
########################################################
# freeIPA Version #
# #
# freeIPA versions are as follows #
# 1.0.x New production series #
# 1.0.x{pre,rc}y Preview/Testing & RC #
# 1.0.0GITabcdefg Build from GIT #
# #
########################################################
########################################################
# This are the main version numbers #
# #
# <MAJOR>.<MINOR>.<RELEASE> #
# #
# e.g. IPA_VERSION_MAJOR=1 #
# IPA_VERSION_MINOR=0 #
# IPA_VERSION_RELEASE=0 #
# -> "1.0.0" #
########################################################
Become IPA v2 beta 1 (2.0.0.pre1)
2010-12-22 13:36:37 -06:00
IPA_VERSION_MAJOR=2
Set VERSION to 2.99.0 on the 3.0 development branch
2011-08-18 15:59:20 -05:00
IPA_VERSION_MINOR=99
Become IPA 2.1.0
2011-08-14 23:34:48 -05:00
IPA_VERSION_RELEASE=0
Redo the way versioning works in freeIPA. The file VERSION is now the sole-source of versioning. The generated .spec files will been removed in the maintainer-clean targets and have been removed from the repository. By default a GIT build is done. To do a non-GIT build do: $ make TARGET IPA_VERSION_IS_GIT_SNAPSHOT=no When updating the version you can run this to regenerate the version: $ make version-update The version can be determined in Python by using ipaserver.version.VERSION
2008-04-30 16:49:52 -05:00
########################################################
# For 'pre' releases the version will be #
# #
# <MAJOR>.<MINOR>.<RELEASE>pre<PRE_RELEASE> #
# #
# e.g. IPA_VERSION_PRE_RELEASE=1 #
# -> "1.0.0pre1" #
########################################################
Become IPA v2 RC 1 (2.0.0.rc1)
2011-02-14 19:12:05 -06:00
IPA_VERSION_PRE_RELEASE=
Redo the way versioning works in freeIPA. The file VERSION is now the sole-source of versioning. The generated .spec files will been removed in the maintainer-clean targets and have been removed from the repository. By default a GIT build is done. To do a non-GIT build do: $ make TARGET IPA_VERSION_IS_GIT_SNAPSHOT=no When updating the version you can run this to regenerate the version: $ make version-update The version can be determined in Python by using ipaserver.version.VERSION
2008-04-30 16:49:52 -05:00
########################################################
# For 'rc' releases the version will be #
# #
# <MAJOR>.<MINOR>.<RELEASE>rc<RC_RELEASE> #
# #
# e.g. IPA_VERSION_RC_RELEASE=1 #
# -> "1.0.0rc1" #
########################################################
Become IPA 2.0.0
2011-03-24 15:28:53 -05:00
IPA_VERSION_RC_RELEASE=
Redo the way versioning works in freeIPA. The file VERSION is now the sole-source of versioning. The generated .spec files will been removed in the maintainer-clean targets and have been removed from the repository. By default a GIT build is done. To do a non-GIT build do: $ make TARGET IPA_VERSION_IS_GIT_SNAPSHOT=no When updating the version you can run this to regenerate the version: $ make version-update The version can be determined in Python by using ipaserver.version.VERSION
2008-04-30 16:49:52 -05:00
########################################################
# To mark GIT snapshots this should be set to 'yes' #
# in the development BRANCH, and set to 'no' only in #
# the IPA_X_X_RELEASE BRANCH #
# #
# <MAJOR>.<MINOR>.<RELEASE>GITxxx #
# #
# e.g. IPA_VERSION_IS_SVN_SNAPSHOT=yes #
# -> "1.0.0GITabcdefg" #
########################################################
IPA_VERSION_IS_GIT_SNAPSHOT="yes"
Replication version checking. Whenever we upgrade IPA such that any data incompatibilities might occur then we need to bump the DATA_VERSION value so that data will not replicate to other servers. The idea is that you can do an in-place upgrade of each IPA server and the different versions own't pollute each other with bad data.
2010-06-24 09:31:52 -05:00
########################################################
# The version of IPA data. This is used to identify #
# incompatibilities in data that could cause issues #
# with replication. If the built-in versions don't #
# match exactly then replication will fail. #
# #
# The format is %Y%m%d%H%M%S #
# #
# e.g. IPA_DATA_VERSION=`date +%Y%m%d%H%M%S` #
# -> "20100614120000" #
########################################################
IPA_DATA_VERSION=20100614120000
Add API version and have server reject incompatible clients. This patch contains 2 parts. The first part is a small utility to create and validate the current API. To do this it needs to load ipalib which on a fresh system introduces a few problems, namely that it relies on a python plugin to set the default encoding to utf8. For our purposes we can skip that. It is also important that any optional plugins be loadable so the API can be examined. The second part is a version exchange between the client and server. The version has a major and a minor version. The major verion is updated whenever existing API changes. The minor version is updated when new API is added. A request will be rejected if either the major versions don't match or if the client major version is higher than then server major version (though by implication new API would return a command not found if allowed to proceed). To determine the API version of the server from a client use the ping command. ticket 584
2011-01-13 13:29:16 -06:00
########################################################
# The version of the IPA API. This controls which #
# client versions can use the XML-RPC and json APIs #
# #
# A change to existing API requires a MAJOR version #
# update. The addition of new API bumps the MINOR #
# version. #
# #
# The format is a whole number #
# #
########################################################
IPA_API_VERSION_MAJOR=2
Add hbactest command. https://fedorahosted.org/freeipa/ticket/386 HBAC rules control who can access what services on what hosts and from where. You can use HBAC to control which users or groups on a source host can access a service, or group of services, on a target host. Since applying HBAC rules implies use of a production environment, this plugin aims to provide simulation of HBAC rules evaluation without having access to the production environment. Test user coming from source host to a service on a named host against existing enabled rules. ipa hbactest --user= --srchost= --host= --service= [--rules=rules-list] [--nodetail] [--enabled] [--disabled] --user, --srchost, --host, and --service are mandatory, others are optional. If --rules is specified simulate enabling of the specified rules and test the login of the user using only these rules. If --enabled is specified, all enabled HBAC rules will be added to simulation If --disabled is specified, all disabled HBAC rules will be added to simulation If --nodetail is specified, do not return information about rules matched/not matched. If both --rules and --enabled are specified, apply simulation to --rules _and_ all IPA enabled rules. If no --rules specified, simulation is run against all IPA enabled rules. EXAMPLES: 1. Use all enabled HBAC rules in IPA database to simulate: $ ipa hbactest --user=a1a --srchost=foo --host=bar --service=ssh -------------------- Access granted: True -------------------- notmatched: my-second-rule notmatched: my-third-rule notmatched: myrule matched: allow_all 2. Disable detailed summary of how rules were applied: $ ipa hbactest --user=a1a --srchost=foo --host=bar --service=ssh --nodetail -------------------- Access granted: True -------------------- 3. Test explicitly specified HBAC rules: $ ipa hbactest --user=a1a --srchost=foo --host=bar --service=ssh --rules=my-second-rule,myrule --------------------- Access granted: False --------------------- notmatched: my-second-rule notmatched: myrule 4. Use all enabled HBAC rules in IPA database + explicitly specified rules: $ ipa hbactest --user=a1a --srchost=foo --host=bar --service=ssh --rules=my-second-rule,myrule --enabled -------------------- Access granted: True -------------------- notmatched: my-second-rule notmatched: my-third-rule notmatched: myrule matched: allow_all 5. Test all disabled HBAC rules in IPA database: $ ipa hbactest --user=a1a --srchost=foo --host=bar --service=ssh --disabled --------------------- Access granted: False --------------------- notmatched: new-rule 6. Test all disabled HBAC rules in IPA database + explicitly specified rules: $ ipa hbactest --user=a1a --srchost=foo --host=bar --service=ssh --rules=my-second-rule,myrule --disabled --------------------- Access granted: False --------------------- notmatched: my-second-rule notmatched: my-third-rule notmatched: myrule 7. Test all (enabled and disabled) HBAC rules in IPA database: $ ipa hbactest --user=a1a --srchost=foo --host=bar --service=ssh --enabled --disabled -------------------- Access granted: True -------------------- notmatched: my-second-rule notmatched: my-third-rule notmatched: myrule notmatched: new-rule matched: allow_all Only rules existing in IPA database are tested. They may be in enabled or disabled disabled state. Specifying them through --rules option explicitly enables them only in simulation run. Specifying non-existing rules will not grant access and report non-existing rules in output.
2011-07-22 08:30:44 -05:00
IPA_API_VERSION_MINOR=11
Reference in New Issue Copy Permalink