Date: Thu, 28 Mar 2024 11:11:12 +0000 (UTC)
Message-ID: <2087600204.6195.1711624272427@ip-10-10-7-29.ec2.internal>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_6194_1684219435.1711624272426"
------=_Part_6194_1684219435.1711624272426
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
InCommon Atlassian
This is the home page for the InC-Atlassian space. This page contains co=
mments and thoughts, posted from various campuses.
A summary of the issues can be found here. NOTE: These issues are not in any par=
ticular order...
Topics:
1) SSL acceleration.
- This was in our original design, fortunately, so we currently run an SS=
L offload and load-balancer appliance (a Citrix NetScaler) in front of the =
Confluence instance. This provides some firewall-like protection and perfor=
mance enhancements. It would be great to be able to wrangle multiple Conflu=
ence machines via the load-balancing feature, but we'll talk a bit more abo=
ut that in the "Clustering" section below. (SC)
2) User account and group management.
- Currently, we take advantage of our campus-wide LDAP resource for user =
authentication. That is great (users can leverage a password they are used =
to using, not generate/maintain something new), but without LDAP group inte=
gration for content authorization, it only takes us so far. So, we've been =
experimenting quite a lot with Atlassian's identity management tool, Crowd.=
The 1.0 - 1.1.1 releases couldn't handle large LDAP directories like our o=
wn (~500,000 user and group objects), but today saw the release of 1.=
1.2 and Atlassian is hopeful that it will take care of most (if not all) of=
our user and group management scalability problems. I'll be digging into t=
hat shortly. (SC)
3) Back-end storage (database, filesystem).
- Confluence taps into our Oracle infrastructure for a database back-end.=
Because of performance concerns in the initial design, we opted to leave a=
ttachments outside of the database and on a filesystem. For that, and for t=
he nightly backup XML files, we mounted a volume provided by our NAS cluste=
r. This seems to work well, but we really wish we could turn it into a clus=
tered and load-balanced Confluence configuration. More on that next...
4) Clustering.
- When Confluence became available, it required that attachments be store=
d in your database, something we had not done (for performance reasons, as =
mentioned above). It would be nice if Atlassian supported an alternate, fil=
esystem-based (via NAS, for example), mechanism for cluster configuration. =
Without that, we would be looking at migrating all of the current attachmen=
ts into the database and that process, while we haven't examined it, doesn'=
t sound like fun. With it, we'd be ready to cluster immediately and could l=
everage our external load-balancing appliance.
5) Mirroring.
- We realized some time ago that Confluence had become an integral part o=
f our daily work and that, when it is unavailable, life becomes difficult. =
To combat this, we devised a plan to erect a secondary Confluence (built as=
a standalone entity - no reliance on NAS, external databases, etc) and pop=
ulate it daily with the previous night's backup of the primary system. This=
would provide emergency access to the Confluence content, especially for t=
hose who might need it to rebuild services in the event of a disaster. We h=
aven't built this yet, but it looks quite doable with a bit of scripting. I=
t would be very handy, though, if Atlassian somehow provided Confluence-to-=
Confluence mirror functionality out-of-the-box.
6) Migration and consolidation.
- We've found that other units who have been running their own wikis=
are, in many cases, quite eager to move all of their content into a centra=
l Confluence service so that they can retire their own wiki and make use of=
Confluence's considerable advantages. Atlassian has provided some really g=
ood tools, which we have utilized, for merging the content of other wiki to=
ols (SnipSnap, etc) into a Confluence instance, but merging all or part of =
a different Confluence instance is not as smooth.
7) Backup and restore.
- I love the simplicity and ease-of-use when it comes to Confluence's bac=
kup and restore procedure. It's one of my favorites, really. Unfortunately,=
though, it only allows you to restore the whole Confluence instance (wipin=
g out everything that was there before the restoration procedure began). Th=
is is great for disaster recovery, but not very practical for fixing user a=
ccidents ("Oops! I deleted my space!" or "Oops! I deleted her space!"). It =
would be very good to have partial restore (space-by-space and page-by-page=
) capabilities.
8) page-watch email bug.
- Any user can set a watch on a space s/he is able to view (to be notifie=
d by e-mail of changes), even if s/he doesn't have a valid e-mail address i=
n his/her profile. If a user without an e-mail address has a watch set on a=
space, any attempts to edit a page in that space results in the resulting =
attempt to send the watch mail failing and this in turn causes the edit att=
empts to fail with a very unhelpful/misleading generic error message. Thus =
a careless action by any one user renders an entire space uneditable.
- There is apparently no way to review which users have watches set on a =
space. This seems to be a glaring omission that makes managing the platform=
much more difficult (due to the bug noted above) and eliminates a very val=
uable piece of information about usage patterns.
- For many reasons it would be much better to at least have the admin opt=
ion of requiring a valid e-mail address in a profile before a user is able =
to complete the registration step.
9) We were running version 2.2.6a.
- Last week, we upgraded to 2.5.3. However as part of their "method 1" (w=
hich we had to do because our database is larger than 2 GB (who's isn't??))=
, we had to point the confluence.home variable at the 2.26a directory to ma=
ke the 2.5.3 instance functional. I'm told by their support that dele=
ting the 2.2.6a directory would kill 2.5.3. They haven't been totally=
clear on what I have to do to eventually get rid of 2.2.6a, but this is a =
bit silly that a new install depends on an older version's directory. =
If there's info they need in there, why isn't it simply copied over at upg=
rade time?
10) Managing Users and Groups.
- (Brown) We are currently running Confluence 2.5.3, wired to our central=
ldap server. Ldap currently has about 18K user objects and 55K group objec=
ts. We use Ldap for user authN (passwords are actually in Kerberos)and for =
authZ. We currently centrally manage the processes for creating new spaces =
and specifying which users and groups can access a given space; we *really*=
want to be able to further delegate this functionality (to departments and=
groups). To do the AuthZ functionality, we rely on the current Confluence =
pages; there are several issues:=20
- a) (Use case CONF-8662) Administration : Manage Groups : View Members o=
f Group : Browse Pagination -- Pagination does not adequately support thous=
ands of members
- b) (CONF-8675) Administration : Manage Groups : Browse Pagination -- LD=
AP queries select every group name for each page load (potentially thousand=
s); Pagination does not adequately support thousands of groups
- c) (CONF-8663) Add Page : Restrictions : Choose Users -- Browse Group M=
embership form violates information security policy by exposing group membe=
rship to end users
- Suggestion -- Provide APIs to make it easier to
- a) use an external tool to manage spaces and manage permissions on thos=
e spaces; this tool might work better in environments with tens of thousand=
s of users and hundreds of thousands of groups,
- b) allow a site to configure Confluence to disable the use of Confluenc=
e's Manage Groups pages.
11) Federated Access.
- (Michael... can you fill this in?)
Hi Chris Phillips (chris dot phillips at Queens u dot ca) from Queen's U=
niversity in Kingston Ontario here. I figure I would jump in and thro=
w some info out there about what we are doing.
We use confluence but are working toward an implementation to integrate =
with the Canadian Federation that we are involved in. We have a draft imple=
mentation page on the go at http://wiki.its.queensu.ca/display/heidm/HowTo=
-+Building+a+Shib+SP+in+Solaris+10+zone+on+Sparc+for+Confluence+Wiki.
Much of the insight was provided by the internet2 reference created by Gar=
y Weaver, but we had to use the regular user objects which I think may caus=
e us some issues in the future.
From a federated standpoint, it's great, especially when you couple the =
Custom Space Usergroups Management Plugin with it. This at least permits yo=
u to push the group management into the space owner which I see as a signif=
icant shortcoming of the native confluence product itself (ie. lack of abil=
ity to delegate group mngmt out of the box that is).
We are at the point where we are engaging with our partners in the feder=
ation to deal with release of appropriate attributes.
We do see a challenge coming down the pipe of for privacy elements and w=
ould like to hear how others dealt with this. (what do you do when someone =
declares that their records should be hidden? Do you replace their co=
mmon name with 'PRIVACY REQUESTED' ??? what about email addresses?
12) Confluence as Content Management System
- from Vince @ UMich) One item that I would add is that we are currently =
looking at Confluence as a possible Content Management System that would re=
place our existing web presence. This would allow content to be created and=
maintained by staff without web programming experience. It would also offe=
r many other benefits including versioning. Once concern we have is how to =
manage public spaces along with internal spaces containing sensitive data. =
We are currently experimenting with this.
13) CROWD
(from Wayne at Umich) Having just got my OpenId to access this wiki, I w=
onder about the future role of CROWD as an integral part of large scale imp=
lementation. CROWD is openid enabled and when we asked about doing user/gro=
up management using an external LDAP server we were told that CROWD is wher=
e the functionality lies.
14) Policy
We use Confluence as our IT wiki supporting around 200 users. One =
of the main issues we ran into was developing good policy. Here are s=
ome example policies:
------=_Part_6194_1684219435.1711624272426--