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 18:
Line 20: − + Line 25:
Line 27: − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 74:
Line 271: − + Line 133:
Line 330: − + Line 182:
Line 379: − The verification phase taking place before release should pick up hard dependencies which could break an update. To the best of my understanding, the 'Verified Package Versions' tab in Rnotes will track hard dependencies - it does what Ian Wells used to do normally and try to build a bug and package dependency graph <span style="color: red;">To be confirmed</span>. + − What needs to be checked manually is where a package fixes three bugs and one was not verified, the so-called soft dependencies. It means that only an older version of that package can be released. Also it can affect other packages if one of the fixes involved multiple packages. <span style="color: red;">To be confirmed</span>+ − The difference between "hard" and "soft" dependencies referred to in this document are:+ − :a) Hard dependencies are those from the spec file, eg: requires: e-smith-lib >= 2.0.0-2 − − Developers put these in when it is necessary to enforce dependencies between packages. − − :b) Soft dependencies relates to .... <span style="color: red;">needs a definition</span> Line 218:
Line 410: − **It would be possible to release e-smith-base 5.0.0-14+ Line 224:
Line 416: − + Line 234:
Line 426: − + Line 325:
Line 517: − + − + Line 335:
Line 527: − + + + + − + Line 430:
Line 625: − + Line 443:
Line 638: + + + + + Line 472:
Line 672: − + Line 478:
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===
===Package Categories===
===Package Categories===
====Sme modified packages.====
====Sme modified packages.====
Changelog generated in-house and includes a reference to a Bug in Bugzilla. Verification required before release.
In the context of the updates cycles, these are packages found in smetest, smeupdates-testing or smeupdates for which an older package can be found in smeos <span style="color: red;"> (To be confirmed)</span>. Changelog generated in-house and includes a reference to a Bug in Bugzilla. Verification required before release.
====Upstream packages====
====Upstream packages====
====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==
*smeupdates-testing to smeudates
*smeupdates-testing to smeudates
Packages can be moved (mv) or copied (cp). For all intent and purposes, only the copy command (cp) is required. These operations are supervised by an automated update script. This script runs every two hours and checks all repositories and tries to do the right thing as far as moving packages around and cleaning up where packages came from. The automated scripts will take care of ensuring all the right actions (eg multiple RPMs, SRPM, removal of older versions) are taken for a particular package, look at the repository update emails (emails from releases@contribs.org) to the updatesteam list to see how it flows. For multiple RPMs (eg clamav) it is only needed to move one RPM, and then the whole family of RPMs and the SRPM moves. Also the scripts ensure that there is always at least one SRPM associated with a family of RPMs (noting that multiple packages can be built from one rpm spec file/tarball/src.rpm).
Packages can be moved (mv) or copied (cp). However in Build, the deletion of files from folders is prohibited, thus (mv) will lead to a (cp). For all intent and purposes, only the copy command (cp) is required. These operations are supervised by an automated update script. This script runs every two hours and checks all repositories and tries to do the right thing as far as moving packages around and cleaning up where packages came from. The automated scripts will take care of ensuring all the right actions (eg multiple RPMs, SRPM, removal of older versions) are taken for a particular package, look at the repository update emails (emails from releases@contribs.org) to the updatesteam list to see how it flows. For multiple RPMs (eg clamav) it is only needed to move one RPM, and then the whole family of RPMs and the SRPM moves. Also the scripts ensure that there is always at least one SRPM associated with a family of RPMs (noting that multiple packages can be built from one rpm spec file/tarball/src.rpm).
So how to move packages? As an example, lets take a clamav set of three RPMS available for version 7. As soon as available, the build system automated script will drop them in smetest.
So how to move packages? As an example, lets take a clamav set of three RPMS available for version 7. As soon as available, the build system automated script will drop them in smetest.
==VERIFICATION==
==VERIFICATION==
A package should be verified using the standard verification template on a clean system, check [[SME Server:Documentation:QA:Verification]] for guidelines. The verification phase should also check for hard/soft dependencies which could break an update, and check for correct changelogs, including a reference to a bug number in bugzilla.
A package should be verified using the standard verification template on a clean system, check [[SME Server:Documentation:QA:Verification]] for guidelines. The verification phase should also check for hard dependencies which could break an update, and check for correct changelogs, including a reference to a bug number in bugzilla.
==RELEASING UPDATES==
==RELEASING UPDATES==
|}
|}
There are two types of package dependencies to check before a release can take place:
:a) Hard dependencies. These dependencies are specified in the spec file, eg: requires: e-smith-lib >= 2.0.0-2. Developers put these in when it is necessary to enforce dependencies between packages. The verification phase taking place before release should pick up hard dependencies which could break an update - the installation and testing of a new rpm will show whether things break or not. To the best of my understanding, the 'Verified Package Versions' tab in Rnotes does not track hard dependencies. <span style="color: red;">To be confirmed</span>.
:b) Soft dependencies. These dependencies occur when a package fixes three bugs and one of them has not been verified. As a result, and until all bugs associated with a particular package are verified, only an older version of that package can be safely released. Also note that unresolved soft dependencies may affect other packages if one of the fixes involves multiple packages. Luckily the 'Verified Package Versions' tab in Rnotes will track this - Rnote script do what Ian Wells used to do manually and try to build a bug and package dependency graph.
As an illustration of soft deps, consider the following scenario, actual bug numbers etc are made up for this example:
As an illustration of soft deps, consider the following scenario, actual bug numbers etc are made up for this example:
*e-smith-base 5.0.0-16 cannot be released as it has a change that has not been verified.
*e-smith-base 5.0.0-16 cannot be released as it has a change that has not been verified.
*It may be possible to release e-smith-base 5.0.0-14
*e-smith-pop3 2.0.0-2 cannot be released as e-smith-base 5.0.0-16 which contains part of the fix for bug 6262 is not being released.
*e-smith-pop3 2.0.0-2 cannot be released as e-smith-base 5.0.0-16 which contains part of the fix for bug 6262 is not being released.
*e-smith-apache 2.0.0-7 cannot be released as part of the fix for Bug 4633 is in e-smith-pop3 2.0.0-1 which is not being released.
*e-smith-apache 2.0.0-7 cannot be released as part of the fix for Bug 4633 is in e-smith-pop3 2.0.0-1 which is not being released.
If you carefully check the code changes it may be possible to release e-smith-pop3 and e-smith-apache in the example above, but safest not to do so.
If you carefully check the code changes it may be possible to release e-smith-pop3 and e-smith-apache in the example above, but safest not to do so.
Note: Shad's automated script doesn't do any blocking of packages. It just tries to sort out where packages should belong based on where things exist when it starts running.
Note: Shad's automated script doesn't do any blocking of packages. It just tries to sort out where packages should belong based on where things exist when it starts running. Accordingly, the script does not prevent the release of packages for which package dependencies have not been resolved.
{| style="color:red;background-color:#ffffcc;"
{| style="color:red;background-color:#ffffcc;"
==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.
:*Step one. Packages created in smetest should be summarely tested by the developer to ensure that it installs correctly. Particular attention should be given to accurate changelog including a reference to the bug report. The bug is then resolved FIXED, and a copy of the changelog including package name provided at time of resolution.
:*Step one. Packages created in smetest should be summarely tested by the developer to ensure that it installs correctly. Particular attention should be given to accurate changelog including a reference to the bug report. The bug is then resolved FIXED, and a copy of the changelog including package name provided at time of resolution.
:*Step two. The package can then be moved by the developer to smeupdates-testing. In practice, members of the updatesteam should ensure that the move has been done, and move all relevant packages on a weekly basis.
:*Step two. The package can then be moved by the developer to smeupdates-testing. Essentially if you can find an older package in smeos then the package should be moved to smeupdates-testing. In practice, members of the updatesteam should ensure that the move has been done, and move all relevant packages on a weekly basis.
:*Step three. Verification takes place, the bug is either REOPENED or resolved VERIFIED. Updatesteam to circulate request for comment about release after having ensured that all deps are satisfied. This could be scheduled in batch weekly unless urgent fix.
:*Step three. Verification takes place, the bug is either REOPENED or resolved VERIFIED. Updatesteam to circulate request for comment about release after having ensured that all deps are satisfied. This could be scheduled in batch weekly unless urgent fix.
===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.
'''Note 1:''': In some instances, centos upstream packages found in smetest and released by us do not show in yum updates notifications on servers in the field. This is because centos has released these packages before we do. We have centos repositories enabled as well as our repositories. We house all the packages necessary for the distro in our repositories. If we ever wanted to disable centos repostories we could do so and still continue to have people with functioning systems and receiving updates. It doesn't hurt (most of the time) to have the centos repositories enabled on servers in the field. It just makes systems get updates to upstream packages quicker. We really should be putting anything that people are able to pull from centos into smeupdates as soon as possible. (Shad)
'''Note 1:''': In some instances, centos upstream packages found in smetest and released by us do not show in yum updates notifications on servers in the field. This is because centos has released these packages before we do. We have centos repositories enabled as well as our repositories. We house all the packages necessary for the distro in our repositories. If we ever wanted to disable centos repostories we could do so and still continue to have people with functioning systems and receiving updates. It doesn't hurt (most of the time) to have the centos repositories enabled on servers in the field. It just makes systems get updates to upstream packages quicker. We really should be putting anything that people are able to pull from centos into smeupdates as soon as possible. (Shad)
'''Note 2:''' Some packages found in smetest belong to smeaddons. If it isn't part of the distro then it doesn't go in smeupdates-testing. smeaddons is just like smecontribs but contains package that were necessary to aid upgrading from 7 to 8. They should be on a similar release schedule to what smecontribs would be. <span style="color: red;">To be confirmed: where to move packages belonging in smeaddons? AND who is responsible for the release of smecontribs related packages (eg unrar)?</span>
'''Note 2:''' Some packages found in smetest belong to smeaddons. If it isn't part of the distro then it doesn't go in smeupdates-testing. smeaddons is just like smecontribs but contains package that were necessary to aid upgrading from 7 to 8. They should be on a similar release schedule to what smecontribs would be. <span style="color: red;">To be confirmed: where to move new packages associated with smeaddons? AND who is responsible for the release of smecontribs related packages (eg unrar)?</span>
==ABOUT THE MIRRORS==
==ABOUT THE MIRRORS==
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]]