3,250
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: + + + − ==OVERVIEW==+ − The SME Server update and maintenance cycle consists of the management of a number of repositories and package categories. Line 25:
Line 27: − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 229:
Line 426: − + Line 320:
Line 517: − + − + Line 330:
Line 527: − + + + + − + Line 438:
Line 638: + + + + + Line 473:
Line 678: − + + + + + + + + + + + − http://mirror.canada.pialasse.com/mirrorlist/smeupdates-8+ − {| style="color:red;background-color:#ffffcc;"+ − |+ − We will need to come up with a tree of which mirrors sync from where so we can see what mirrors are affected by issues or outages.+ − |}
→Initscript packages.
'''This page is in a Draft stage and still requires additions and clarifications.'''
'''This page is in a Draft stage and still requires additions and clarifications.'''
{{Level|Developer}}
==OVERVIEW==
The SME Server update and maintenance cycle consists of the management of a number of repositories and package categories.
In order to help in the release cycle, mainly on pushing upstream packages at the right place, you can refer with some caution to this script : http://canada.pialasse.com/SMErepo/
===Repositories===
===Repositories===
====Clamav packages.====
====Clamav packages.====
This is a special case. Whilst not build by SME, and due to problem having been experienced in the past, these packages (three of them) are attached to a single SME bug in bugzilla. There is no specific changelog, however verification is recommended before release.
This is a special case. Whilst initially not build by SME, and due to problem having been experienced in the past, these packages (three of them) are attached to a single SME bug in bugzilla. There is no specific changelog, however verification is recommended before release.
====Initscript packages.====
This is a special case up to SME9 (including). Rebuild by SME every time upstream release a higher version to what we built. We import the new package in CVS and apply our patches.
so first import new srpm<syntaxhighlight lang="bash">
cd smeserver/rpms/initscripts/sme9
wget http://vault.centos.org/
../../common/cvs-import.sh -b sme9 -m "import initscript from centOS" initscripts-.....el6.centos.src.rpm
</syntaxhighlight>
second restore needed patches<syntaxhighlight lang="bash">
rm -f initscripts-9.03.31-runlevel7.patch initscripts-9.03.40-dmesg.patch initscripts-9.03.40-slapd_alias_ldap.patch initscripts-9.03.46-dont_run_plymouth_if_disabled.patch
cvs update -dPA
cvs update -p -r 1.2 initscripts-9.03.31-runlevel7.patch > initscripts-9.03.31-runlevel7.patch
cvs add initscripts-9.03.31-runlevel7.patch
cvs update -p -r 1.1 initscripts-9.03.40-dmesg.patch > initscripts-9.03.40-dmesg.patch
cvs add initscripts-9.03.40-dmesg.patch
cvs update -p -r 1.1 initscripts-9.03.40-slapd_alias_ldap.patch > initscripts-9.03.40-slapd_alias_ldap.patch
cvs add initscripts-9.03.40-slapd_alias_ldap.patch
cvs update -p -r 1.1 initscripts-9.03.46-dont_run_plymouth_if_disabled.patch > initscripts-9.03.46-dont_run_plymouth_if_disabled.patch
cvs add initscripts-9.03.46-dont_run_plymouth_if_disabled.patch
</syntaxhighlight>
For SME the patch to add in spec file:
Patch2000: initscripts-9.03.31-runlevel7.patch
Patch2001: initscripts-9.03.40-dmesg.patch
Patch2002: initscripts-9.03.40-slapd_alias_ldap.patch
Patch2003: initscripts-9.03.46-dont_run_plymouth_if_disabled.patch
in %setup we add :
%patch2000 -p1
%patch2001 -p1
%patch2002 -p1
%patch2003 -p1
then update the changelog, <syntaxhighlight>
%changelog
* date your name <email> - version release
- Rebase on upstream ...'''version'''... [SME '''...''']
- Don't try to run plymouth if disabled [SME: 8375]
Code from Charlie Brady
- Make slapd service an alias for ldap [SME: 8635]
- Add -n 1 to the dmesg line in rc.sysinit to prevent unwanted
messages appearing on the console [SME: 8277]
- Add hack for running rc7.d script during runlevel 4 [SME: 7217]
</syntaxhighlight>
the release version is the same as upstream and we add trailing release number :
Release: 1%{?dist}.1
If you are lucky the previous patches will still work, otherwise you will need to manually modify and create new patches.
==== Samba ====
As per SME 10 we build our own version of Samba from upstream in order to enable few functions to allow Samba AD usage. All modifications are done in the spec file.
the changes are the following :<syntaxhighlight lang="bash">
--- samba.spec.original 2016-10-02 16:23:04.356835288 -0700
+++ samba.spec 2016-10-02 16:31:38.311833030 -0700
@@ -38,1 +38,1 @@
-%global with_internal_ldb 0
+%global with_internal_ldb 1
@@ -59,8 +59,8 @@
%global libwbc_alternatives_suffix -64
%endif
-%global with_mitkrb5 1
-%global with_dc 0
+%global with_mitkrb5 0
+%global with_dc 1
%if %{with testsuite}
# The testsuite only works with a full build right now.
@@ -399,2 +399,3 @@
Summary: Samba libraries
Group: Applications/System
+Requires: libldb
@@ -463,7 +464,7 @@
Requires: %{name}-libs = %{samba_depver}
Requires: python-tevent
Requires: python-tdb
-Requires: pyldb
+#Requires: pyldb
Requires: pytalloc
Provides: samba4-python = %{samba_depver}
@@ -864,8 +865,8 @@
%endif
install -d -m 0755 %{buildroot}%{_unitdir}
-for i in nmb smb winbind ; do
- cat packaging/systemd/$i.service | sed -e 's@\[Service\]@[Service]\nEnvironment=KRB5CCNAME=FILE:/run/samba/krb5cc_samba@g' >tmp$i.service
+for i in nmb smb winbind samba; do
+ cat packaging/systemd/$i.service | sed -e 's@\[Service\]@[Service]\nEnvironment=KRB5CCNAME=/run/samba/krb5cc_samba@g' >tmp$i.service
install -m 0644 tmp$i.service %{buildroot}%{_unitdir}/$i.service
done
%if %with_clustering_support
@@ -1481,1 +1481,2 @@
%{_mandir}/man8/samba-tool.8*
+%{_unitdir}/samba.service
%else # with_dc
@@ -1738,6 +1743,7 @@
%{_libdir}/samba/libHDB-SAMBA4-samba4.so
%{_libdir}/samba/libasn1-samba4.so.8
%{_libdir}/samba/libasn1-samba4.so.8.0.0
+#%{_libdir}/samba/libdfs_server_ad.so
%{_libdir}/samba/libgssapi-samba4.so.2
%{_libdir}/samba/libgssapi-samba4.so.2.0.0
%{_libdir}/samba/libhcrypto-samba4.so.5
</syntaxhighlight>
here is how to upgrade the rpm from uptream.
<syntaxhighlight lang="bash">
cd /smeserver/rpms/samba/sme10/
make clean
make prep
cvs update -dPA
# here check the last revision of patch and reuse it
cvs status samba.spec.patch
# check the last version of samba and get its link in the following command
wget https://vault.centos.org/...../samba-4.6.2-12.el7_4.src.rpm
common/cvs-import.sh -b sme10 samba-4.6.2-12.el7_4.src.rpm -m "upgrade to samba-4.6.2-12"
cvs update -dPA
make clean
make prep
#update here the correct version of patch, ie 1.3 to something else
cvs update -p -r 1.3 samba.spec.patch > samba.spec.patch
cvs add samba.spec.patch
patch <samba.spec.patch
</syntaxhighlight>if patch fails, you need to update the patch, see bug https://bugs.contribs.org/show_bug.cgi?id=10429 as reference.
Then edit the spec file to add changelog lines and update release, commit and build. Ideally in the changelog paste the elements from previous spec files of SME related work, so we keep track
Also to note there are some upstream related package that should not be updated (ie, not pushed to smeupdates or smeos) without rebuilding samba locally first :
* libtevent
* python-tevent
also the following are exclude as they are build locally with samba srpm
* samba,samba-client,samba-client-libs,samba-common,samba-common-libs,samba-common-tools,samba-libs,samba*,libsmbclient,libwbclient
====Anaconda packages.====
This is a special case. We always rebuild our installed to include our special way. Here is the list of patch for SME9
Patch10001: 0001-anaconda.id.displayMode.patch
Patch10002: 0002-RemovePartitionTypeDialog.patch
Patch10003: 0003-SMEServerBranding.patch
Patch10004: 0004-UTC.patch
Patch10005: 0005-DegradedRAID1.patch
Patch10006: 0006-InstallerHDWarning.patch
Patch10007: 0007-VolGroup.patch
Patch10011: 0011-CheckArch.patch
Patch10012: 0012-CheckArch2.patch
Patch10013: 0013-Limit-languages.patch
Patch10014: 0014-Make-boot-loader-use-SME-labels.patch
Patch10015: 0015-Determine-upgradability-of-SME-server.patch
Patch10016: 0016-Automatically-upgrade-bootloader-if-necessary.patch
Patch10017: 0017-Headless-install.patch
Patch10018: 0018-RaidN.patch
Patch10019: 0019-UpgradeText-whitespace.patch
Patch10020: 0020-PreventTooOldUpgrades.patch
Patch10021: 0021-RaidN-v2.patch
Patch10022: 0022-InstallerLanguages.patch
Patch10023: 0023-remove_empty_line_in_lang_table.patch
then in %prep after %setup and centos patches add:
%patch10001 -p1
%patch10002 -p1
%patch10003 -p1
%patch10004 -p1
%patch10005 -p1
%patch10006 -p1
%patch10007 -p1
%patch10011 -p1
%patch10012 -p1
%patch10013 -p1
%patch10014 -p1
%patch10015 -p1
%patch10016 -p1
%patch10017 -p1
%patch10018 -p1
%patch10019 -p1
%patch10020 -p1
%patch10021 -p1
%patch10022 -p1
%patch10023 -p1
then update the changelog, the release version is the same as upstream and we add trailing release number :
Release: 1%{?dist}.1
If you are lucky the previous patches will still work, otherwise you will need to manually modify and create new patches.
====Contribs.====
====Contribs.====
Not part of the updatesteam maintenance cycle. Verification and release are managed by individual maintainers, however contribs packages are created in smetest, then moved direct to smecontribs - they do not appear in smeupdates-testing.
Not part of the updatesteam maintenance cycle. Verification and release are managed by individual maintainers, however contribs packages are created in smetest, then moved direct to smecontribs - they do not appear in smeupdates-testing.
====Other packages to pay attention====
GeoIP on SME 8 and SME9: the package present in smetest should not be pushed (GeoIP-1.6.5-2), as it creates some conflicts. Hence, we keep GeoIP-1.4.8-1.
==BUILD SYSTEM==
==BUILD SYSTEM==
==ISSUE RELEASE NOTES==
==ISSUE RELEASE NOTES==
Wait for the mirrors to sync, and then email manually the release notes.
Wait for the mirrors to sync, and then email manually the release notes. Release notes can be prepared manually, or one can access ALL draft release notes for sme7 and sme8 by just looking at http://wellsi.homeip.net/rnotes/notes/ . Check the "Bug Report" in the section about RNOTES below for details.
Example of release notes:
Example of release notes:
===Status.===
===Status.===
Status of each bug. The bugzilla product is highlighted if not matching the SME Version
Status of each bug. The bugzilla product is highlighted if not matching the SME Version.
You may see entries like ‘7026 <No Product Found> Access Denied’ that means it is a security bug.
[You may see entries like ‘5908 NA <No Product Found> Access Denied’ that means it is a security bug.]
===Simple.===
===Simple.===
===Verified Package Versions===
===Verified Package Versions===
This tab gives some hints as to which packages can be released to smeupdates - if it’s all green then it should be good to go.. It does not yet check the depends/blocks from bugzilla. It also only goes green when a bug and all dependents are Verified. When it cannot retrieve the status (as is the case with security bugs) it marks them as NA and colours them black, manual checking is advised.
This gives some hints to which packages can be released to smeupdates.
It does not yet check the depends/blocks from bugzilla.
It also only goes green when a bug and all dependents are Verified.
When it cannot retrieve the status it colours them black, manual checking is advised.
===Smetest Files===
===Smetest Files===
This tab lists packages provided as part of a SME Server release <span style="color: red;">(with reference to smeos exclusively? - to be confirmed)</span> which have a newer version in smetest. It is likely that these should be moved to smeupdates-testing.
This tab lists packages provided as part of SME Server release which have a newer version. Only files that were on the ISO are checked and displayed - it is likely that these should be moved to smeupdates-testing. Note that Smetest may also contain other updated files related to contribs - and potentially other files. These are not displayed in RNotes and need to be sorted manually.
:Note 1: when compiling status of updates it is good to cross-reference the actual packages (RPMs) in the release queue (smetest/smeupdates-testing) with the bugzilla matrix and investigate where they don't match.
:Note 1: when compiling status of updates it is good to cross-reference the actual packages (RPMs) in the release queue (smetest/smeupdates-testing) with the bugzilla matrix and investigate where they don't match.
===Scenario Three: Upstream packages and kernel mods excluding clamav===
===Scenario Three: Upstream packages and kernel mods excluding clamav===
{| style="color:red;background-color:#ffffcc;"
|
This topic is incomplete and requires additional information
|}
:*Step one. Identify relevant packages by looking at all the RPMs, Changelogs, and Bugzilla. To find the upstream RPMs compare smetest to smeos. Rnotes simplify this process.
:*Step one. Identify relevant packages by looking at all the RPMs, Changelogs, and Bugzilla. To find the upstream RPMs compare smetest to smeos. Rnotes simplify this process.
Ibiblio appears to be unreliable, making it difficult to track changes. This is because Ibiblio is experiencing intermittent full hard drive issues. All downstream mirrors from them thus also have issues. Historically ibiblio was the place to see if packages had propagated out of the buildsys.
Ibiblio appears to be unreliable, making it difficult to track changes. This is because Ibiblio is experiencing intermittent full hard drive issues. All downstream mirrors from them thus also have issues. Historically ibiblio was the place to see if packages had propagated out of the buildsys.
We've recently moved our primary mirror to the CA mirror (mirror.canada.pialasse.com). That is the one that you should check for what should actually be on the mirrors. You can always check to see what mirrors systems should be using for updates by looking at the mirrorlist files that are generated and housed on the CA master mirror.
We've recently moved our primary mirror to a new set of mirrors:
*mirror.canada.pialasse.com : Canada, Montréal (known as the CA Mirror)
*mirror.pialasse.com : in France, Roubaix near Lille.
The CA Mirror is the one that you should check for what should actually be on the mirrors. You can always check to see what mirrors systems should be using for updates by looking at the mirrorlist files that are generated and housed on the CA master mirror.
As an example:
As an example:
http://mirror.canada.pialasse.com/mirrorlist/smeupdates-8
Both mirrors can be used for rsync subject to being added to the list of allowed client (canadian server or french ones). Alternatively, mirrorservice.org has reopened their mirror with a 4 hour sync and a public rsync service ( they are based in UK and sync on the canadian mirror)
=== Current SME Server contribs.org Mirror Tree ===
[[Image:Smeserver_mirrors.png|600px| ]]<br />
this is the current tree of Mirror for SME Server, so we can see what mirrors are affected by issues or outages.
For a full list of our download mirrors see our [http://mirror.contribs.org/mirrors/ '''download locations''']
[[Category:Howto]]
[[Category: Development Tools]]