Gitolite macro to expand to user name? - gitolite

I have a config file with something like:
repo qt/[a-zA-Z0-9_\.\-]+
C = #admins
RW+ = #admins
R = #users
RW bob = bob
As you can see every user (in group #users) can read all branches
and I want bob to be able to create and push to a branch bob (and also to bob/fix and so on).
Is there a macro that would expand to the users name?
I would like to do something like:
repo qt/[a-zA-Z0-9_\.\-]+
C = #admins
RW+ = #admins
R = #users
RW USER = USER

The one Gitolite feature which would look close to what you want is "personal branch"
"Personal" branches are great for environments where developers need to share work but can't directly pull from each other (usually due to either a networking or authentication related reason, both common in corporate setups).
Personal branches exist in a namespace of their own. The syntax is
RW+ personal/USER/ = #userlist
where the "personal" can be anything you like (but cannot be empty), and the "/USER/" part is necessary (including both slashes).
A user "alice" (if she's in the userlist) can then push any branches inside personal/alice/.
Which means she can push personal/alice/foo and personal/alice/bar, but NOT personal/alice.
(Background: at runtime the "USER" component will be replaced by the name of the invoking user. Access is determined by the right hand side, as usual).
That means, when you are looking for "Is there a macro that would expand to the users name?", /USER/ would be an example of a "macro" expended to the username.

Related

What makes Outlook/Exchange able to resolve a recipient or not?

I am trying to test whether staff are still employed in the organization.
The best approach I have found so far has to try send them an email.
So, using Outlook, Exchange and Python, I put the email addresses into a new email and try "Resolve" the recipient.
The behavior seems erratic. In most cases, this will produce a result, or "None".
for recipient in msg.Recipients:
try:
exchangeSays = recipient.AddressEntry.GetExchangeUser()
But now in my test case, I have a person john.smith#company.com and whilst the person does exist, is real and present, the entry will not resolve.
I've also noticed that sometimes email addresses resolve to "John Smith" and other recipients will resolve to "john.smith#company.com". I know it's resolved when the name is underlined in the email window.
What's going on here? Some questions:
Is this the best way of checking whether an person is still current?
Am i doing something wrong in my attempt to resolve the recipient?
Firstly, there is no need to create a message and send it - use Application.Session.CreateRecipient / Recipient.Resolve. If Recipient.Resolve returns true, check Recipient.AddressEntry.Type, If it is "EX", the name was resolved to a GAL user. You can however run into problems if you have a contact with the same name in your Contacts folder, and OOM does not allow to resolve against a particular container (e.g. GAL).
Note that Outlook Object Model cannot handle ambiguous names (e.g. "John Smith" will also match "John Smither") - it will simply return an error. If using Redemption is an option (I am its author), it exposes RDOSession.AddressBook.ResolveNameEx, which returns a list of matches.
On the Extended MAPI level (PR_ANR restriction) you can also resolve against a particular container, but OOM does not expose that functionality. In Redemption, you can use RDOSession.AddressBook.GAL.ResolveName/ResolveNameEx. Note however that in this case GAL provider won't resolve an SMTP address of a GAL user (go figure).
Outlook (UI only) also exposes search containers (PR_SEARCH in MAPI, you can see the one exposed by GAL if you click Ctrl + Shift + B to open the address book, then click Tools | Find). You can specify one or more fields to match (e.g. the whole display name or first and last names separately), but OOM, again, does not expose it. In Redemption, you can use RDOSession.Addressbook.GAL.Search:
set Session = CreateObject("Redemption.RDOSession")
Session.MAPIOBJECT = Application.Session.MAPIOBJECT
set AddrList = Session.Addressbook.GAL
set Search = AddrList.Search
Search.FirstName = "John"
Search.LastName = "Smith"
set AddressEntries = Search.GetResults
for each AddressEntry in AddressEntries
MsgBox AddressEntry.Name
next

How to set a `User cap` for a particular domain in Gitlab

Original question:
I want to limit the number of users from a particular domain that can register into my Gitlab instance. I noticed that I could set a "user cap", but it wasn't specific to a domain.
For example:
I want to limit the number of users registered from these domains. 20 users from testdomain1.com and 30 users from testdomain2.com are allowed to sign up. So, if there are already 20 users registered sucessfully from testdomain1.com, new user from testdomain1.com will not be allowed to sign up.
What should I do for it?
2021.11.18 Edited:
I added a validate to the User model:
# gitlab/app/models/user.rb
class User < ApplicationRecord
# ...
validate :email_domain, :ensure_user_email_count
# ...
def email_domain
email_domain = /\#.*?$/.match(email)[0]
email_domain
end
def ensure_user_email_count
# select count(*) from users where email like '%#test.com';
if User.where("email LIKE ?", "%#{email_domain}" ).count >= 30
errors.add(email_domain, _('already has 30 registered email.'))
end
end
end
This validate can set "user cap = 30" for each domain but it's still not able to set a "User cap" for a particular domain.
Since the related issue post did not get any response yet. I'm tring to implement it by myself. And it seems like that I need to extend the UI of the Admin Settings page and add some related tables to database to set different "user cap" for different email domain.
The GitLab user cap seems to be per GitLab instance.
So if both your domains are reference the same GitLab instance, you would have only one user cap possible.
But if each of your domain redirects to one autonomous GitLab instance (per domain), then you should be able to set user cap per domain.
The OP Ann Lin has created the issue 345557 to follow that feature request.
TRhe OP reports:
A particular table is needed to store the caps.
But I don’t have enough time now to modify the UI so I found a simple way to do this:
The Allowed domains for sign-ups which called domain_allowlist in database is a text:
gitlabhq_production=# \d application_settings
...
domain_allowlist | text | | |
...
gitlabhq_production=# select domain_allowlist from >application_settings;
domain_allowlist
-------------------
--- +
- testdomain1.com+
- testdomain2.com+
(1 row)
I can modify the testdomain1.com to testdomain1.com#30 to store the user cap and use Regex to get the number 30.
I will modify the UI and add the database table later. And I’ll create a pull request on Gitlab when I’m done.

gitolite-config with user-name in branch pattern possible?

I want to configure something like
#developer = user1 user2
repo test
C ^dev/$user- = #developer
RW+ ^dev/$user- = #developer
So that each user in #developer has complete control over all corresponding branches under dev/ with the user-name in it.
Is there a way to make something like that happen?
Yes, this is possible:
#developer = user1 user2
repo test
RW+ dev/USER/ = #developer
(There might be some syntax errors in that snippet, I did not test it.)
See https://gitolite.com/gitolite/user.html#personal-branches for details.

How do I import members of one GitLab group into another

Does somebody know how I can import all members of one group into another in GitLab, rather than doing it manually one by one?
The only native feature which comes close is in lib/tasks/gitlab/bulk_add_permission.rake, which is mentioned in "User management"
# omnibus-gitlab
sudo gitlab-rake gitlab:import:all_users_to_all_groups
# installation from source
bundle exec rake gitlab:import:all_users_to_all_groups RAILS_ENV=production
You could take that as a model to develop our own task.
I am not aware of such a feature. But you can script it with the API. We use it here to add all users to one single group (all users to all groups is not feasible for our case).
Helpful documentation: http://doc.gitlab.com/ce/api/README.html, http://doc.gitlab.com/ce/api/users.html and http://doc.gitlab.com/ce/api/groups.html
There is also a respond to another question that might be helpful and lists also various modules for various programming languages: Is there a way to add users automatically into gitlab?
I was looking for a solution to Assign all Gitlab users to one particular group.
Here's the solution:
Create this file:
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/finder_import.rake
With this content:
namespace :gitlab do namespace :finder do
desc "GitLab | Add all users to group Colaboradores (admin users are added as owners)"
task importall: :environment do |t, args|
user_ids = User.where(admin: false).pluck(:id)
admin_ids = User.where(admin: true).pluck(:id)
groups = Group.where(name: "Colaboradores")
puts "Importing #{user_ids.size} users into #{groups.size} groups"
puts "Importing #{admin_ids.size} admins into #{groups.size} groups"
groups.each do |group|
puts "Importing into #{group.name}"
group.add_users(user_ids, GroupMember::DEVELOPER)
group.add_users(admin_ids, GroupMember::OWNER)
end
end
end end
Run this command:
gitlab-rake gitlab:finder:importall

Postfix and save to sent mail dir

I know this might be a dummy question or a question that comes from lack of knowledge, but I hope someone can still answer it. I did try to read a lot of Postfix documentation but found no answer to this. I don't even know if it's a Postfix specific or mail servers general question.
So I have a mail server, just a clean Postfix install that delivers email.
I've defined my users and connected with IMAP and SMTP using Thunderbird.
When I went to Thunderbird account settings and disabled "place a copy", Postfix did not put a copy of the sent message in the user .Sent folder.
However, I've also connected my Gmail, Hotmail or Yahoo mail and disabled the "place a copy" and still have a copy in the sent items folder.
So in this case there are 2 options:
Something is wrong with my Postfix configuration
Gmail, Hotmail, Yahoo put a copy in their sent folder as a different process on the server side
Just for the record, having searched around for a how to, and not finding one, I am posting it here:
The only (easy) way I've found to save sent emails is the sender_bcc solution (with it's attendant faults):
I am using postfix / dovecot / sieve / mysql virtual boxes
In /etc/postfix/main.cf add:
sender_bcc_maps = mysql:/etc/postfix/mysql-virtual-bcc-maps.cf
Create file /etc/postfix/mysql-virtual-bcc-maps.cf:
user = (database user)
password = (database password)
hosts = 127.0.0.1
dbname = (database databasename)
query = SELECT CONCAT_WS('',LEFT('%s', LOCATE('#', '%s')-1),'+sent#',SUBSTRING('%s', LOCATE('#', '%s')+1)) AS destination FROM virtual_users WHERE email='%s' AND autosent=1
You'll note in my query, I've added a (tinyint default 0) column to my virtual_users table so I can turn on/off this automatic sent items feature per user. This query takes the sender email address that postfix gives it, splits it in half at the # sign, and adds +sent to the address so it looks like sender+sent#domain.tld. This allows sieve in the next step to pick it up and drop it straight to sent items.
In /etc/dovecot/sieve/default.sieve add:
require ["fileinto", "mailbox", "envelope", "subaddress","imap4flags"];
if envelope :detail "to" "sent" {
addflag "\\Seen";
fileinto :create "Sent";
stop;
}
Also helpful to modify /etc/dovecot/conf.d/15-mailboxes.conf and add the auto subscribe to sent (and junk and trash and others for that matter):
mailbox Sent {
special_use = \Sent
auto = subscribe
}
I think that is all (I'm posting this the next day after doing it, so I think I got it all...)
Postfix itself does not place copies of sent messages anywhere; it receives messages and delivers them to the recipient. Saving sent messages to your own mailbox is the responsibility of your user agent (Thunderbird, in your case).
It's important to understand that Postfix (and other traditional Unix SMTP servers) don't have a "user" concept. Yes, if so configured it's possible to authenticate by supplying a username and a password, but Postfix doesn't use this identity information.
That said, it's not impossible to configure Postfix to do what you expected – sender_bcc_maps can be used to add a recipient to messages sent by you, and by adding yourself and using a filter in your mail client (or mail delivery agent like procmail) you can make sure that messages sent by you end up in the Sent folder.
I am running a Installation with automatic copies created by sender_bcc_maps. It's working fine. You have to check the sender, otherwise everyone can create sent mails in foreign sent folders.
I have solved it with two virtual domains. One for the user and one for the copy.
But there is a big problem with sender_bcc_maps. All bcc senders will be deleted in the sent copy. You cannot see anymore, who got a blind copy of this mail.
As 'ego2dot0' said above, you don't need any MDA filters (sieve etc.) to do this. It can be done using Postfix alone, although it took me a while to figure out how to do it.
You have to use sender_bcc_maps AND virtual_mailbox_maps features together.
You have to use a virtual domain dedicated specially for copies to self. If your actual domain is "your.domain.tld", you can use eg. subdomain "copyself.your.domain.tld". This subdomain does not have to actually exist, ie. be defined in the DNS (moreover, it's better that it isn't defined, so nobody accidentally sends mail to it from outside). It is a purely virtual domain that is recognized only by Postfix.
1) Configure sender_bcc_maps to BCC mail coming from user#your.domain.tld to user#copyself.your.domain.tld. You can do it for only a few selected users using a regular "hash" type map, or you can do it for all users at once using PCRE type map and regular expressions.
2) You have to define your virtual domain in virtual_mailbox_domains, like this:
virtual_mailbox_domains=copyself.your.domain.tld
3) Configure virtual_mailbox_maps so that the destination mailbox for address "user#copyself.your.domain.tld" is the actual "Sent" mailbox of the user "user". For example (assumed that you are using regular system users and Maildir format - like in my case) the path to "Sent" mailbox for user "user" will be "/home/user/Maildir/.Sent". So, you can define common part of the path as virtual_mailbox_base, eg.
virtual_mailbox_base=/home
and then in the virtual mailbox map enter the rest of the path like this:
user#copyself.your.domain.tld user/Maildir/.Sent/
(the trailing / is important to indicate the Maildir format).
Again, you can use PCRE type map to do this for all users.
4) To properly save mail to the mailbox, Postfix need to also know the proper UID and GID for the particular user, so you have to use virtual_uid_maps and virtual_gid_maps parameters as well. If you are using virtual users, it's probably enough to define "static" type maps specifying a single UID and GID of the system user that owns all the virtual mailboxes. However, if you are using system users like me, you need the proper actual UID and GID for any user. If you have only a few users, you can use a regular "hash" type map, with entries like these:
user#copyself.your.domain.tld 2001
or you can try to setup a pipeline with "pipemap" map type, that uses some PCRE maps and "unix:passwd.byname" map to obtain the UIDs and GIDs for all users (I haven't done this part, as my Postfix installation is compiled without "pipemap" type support).
So to sum everything up, use something like this:
In /etc/postfix/main.cf file, add the following lines:
sender_bcc_maps=hash:/etc/postfix/sender_bcc
virtual_mailbox_domains=copyself.your.domain.tld
virtual_mailbox_base=/home
virtual_mailbox_maps=hash:/etc/postfix/copyself
virtual_uid_maps=hash:/etc/postfix/copyself_uids
virtual_gid_maps=hash:/etc/postfix/copyself_gids
/etc/postfix/sender_bcc contains a bunch of lines like:
user#your.domain.tld user#copyself.your.domain.tld
/etc/postfix/copyself contains - respectively - lines like:
user#copyself.your.domain.tld user/Maildir/.Sent/
/etc/postfix/copyself_uids and /etc/postfix/copyself_gids contain - respectively - lines like:
user#copyself.your.domain.tld 2001
I have done this on my server and it works great for me.

Resources