I had originally asked the original, closely-related question on superuser.com, but I feel this might be a little more stackoverflow speed since I want something programmatic and automated, using tools no one there knows well. Here is the scenario:
Two accounts:
Account A (original work account with
quota)
Account B (new backup email
account)
Process:
Create folder in Account B (e.g. "2010 Email Backup" folder).
Migrate all folders in Account A nested into new folder on Account B (e.g. "2010 Email Backup" -> "Inbox", "Sent", "Trash", etc.).
I want to be able to do this every couple of months or every year, and script it for my needs with either imapsync or offlineimap. So: will using these tools, if this is possible, cause an issue when it checks Account A and clears out Account B because the original folders are different? I am not sure how specific they are, so I wanted some reports from the field. If anyone has experience with these tools, PLEASE let me know. I would love to figure this out before I hit a quota.
From the imapsync FAQ:
Q. I have moved from Braunschweig to Graz, so I would like to have my
whole Braunschweig mail sorted into a folder INBOX.Braunschweig of my
new mail account.
R.
1) First try (safe mode):
imapsync \
...
--regextrans2 's/INBOX(.*)/INBOX.Braunschweig$1/' \
--dry --justfolders
2) See if the output says everything you want imapsync to do,
--dry option is safe and does nothing real.
3) Remove --dry.
Check the imap folder tree on the target side.
4) Remove --justfolders.
Good tip, never realized you could use --dry or pick another folder with --regextrans2
Could of been possible with:
--prefix1 INBOX.Braunschweig
You might also want to use --subscribe to make sure that you don't have any folders your not subscribed to that could otherwise get missed.
We actually wrote a cPanel IMAPSYNC too.
Related
I am using the latest versions on 2sxc (11.05) and the Content App on DNN 9.06. The Content-Type for Locations does not have a field for Region (or State). Is there already something in place to account for that to get Canadian or US addresses to output normally? I realize I can add the field and then maybe use the Dropdown from Query to hook it up to DNN's list of Regions, and then modify the Views accordingly...
But that seems like a lot of work for something that might already be built in (and I just don't see it?). Or is there another easy way to tackle this?
Truth be told - we never needed that so far, so it doesn't exist.
Is this necessary for maps to work, or just another field which a standard us-address needs? I'm curious because neither outlook nor SharePoint seem to require such a field, so I never really thought about it.
BUT: if you do implement it, please do share it back with us, so we can publish it.
Note that if this is important, a possibly nicer solution would be to use a public api somewhere which provides this information, as it's most certainly more complete & up to date for this purpose. If this is the case, ping me and I'll implement a string-dropdown-from-json or something like that :)
The scenario is as follows: A user has opened a merge request that adds a new feature to my code. Their code however contains a few bugs. I know how to fix the appropriate parts but I'd prefer keeping my repository free of code that has known issues. Therefore I'd like to modify their code before merging it.
I know I could also manually copy over the changes but I would still like to give the user that opened the merge request credit for their contribution.
You could take the user's changes (pull them over to your development environment) using Git, and then add your changes, and then merge the lot -- this way your user's commits are visible, and your commits are visible.
You could also add your user to a CREDITS file to give them credit as a contributor.
You could also ask the user to fix the bugs (which helps the user too, to learn how to improve their code) and then merge the change.
How can I extract all the attachments coming to the postfix email server? in order to save it to another (efficient) file server. I don't want to log in for every user and extract the attachments for the individual users but extract all the attachments (as file objects or file stream) as it comes to the postfix server and save it. While extracting, the routine should know which user an attachment belong but it should not go by user way. I specially want to avoid the login session/cycle.
As the second option - if I can get a push notification about a users attachment as it arrives. I am sure there are ways to do that - please let me know best ways to do it. And then extract attachment(s) for the user whose email with attachment(s) has just arrived. Still, I don't want log-in/out cycle to extract. It has to be done such a way that no individual password would be necessary.
Guessing lot of solutions would come in in python, thats great though. It would be also helpful if I get some NodeJS solution to do this.
Please help, and don't mix your solution with these two options - one at a time solution please - either one :)
Have a thorough google for postfix, procmail and uudeview - That combo will allow you to save attachments on a file server.
As a starting point have a look here:
https://kuther.net/howtos/howto-receive-mail-and-save-attachment-fetchmail-procmail-and-metamail
...and here...
http://www.mugginsoft.com/content/postfix-automatically-decode-zipped-attachments
HTH
Regards
Frank
I am trying to programmatic-ally set the Gnome 3/GDM 3 user profile/tile/face picture for a user's account in Gnome3/GDM. This is my first attempt at a simple program for Linux and I'm unfamiliar with the APIs and my searching has yielded little useful information. It seems like one can write data to a .face file but this doesn't seem to take affect (or perhaps my file type/specs are wrong). I found from this forum post that the information is stored in a user-specific directory under /var/lib/AccountsService/users, however I want my program to run with regular user privileges and writing (directly) to this file would require elevated privileges (despite an unprivileged user being able to specify an image for their account via the Gnome settings GUI).
Ideally, I would like to do the same for KDE/KDM and Gnome 2 versions as well. Any information would be greatly appreciated. Thanks!
OK, here's the part I can shed some light on:
On any Unix'y OS, you can always fall back on the GECOS field update function putpwent. Traditionally, the “Real Name” is the first part of the GECOS field in the user record, up to the first ,. Different systems store different extended information after the ,, including things like department names, home and office phone numbers and the like.
In Gnome 2, “they” used to use ~/.face as your personal face icon. However, there are all kinds of situations in which one user can't look into another's home folder (including root: things like network filesystems, encrypted loopback homes, and more), so this was abandoned at some point (I believe 3.0) in favour of the /var/lib/AccountsService/icons/$YOURNAMEHERE location.
In the spirit of Gnome 3, the new system (the one you most likely want to use) is the Accounts Services DBus service. You can obtain a user object over DBus, and alter it. The interface is org.freedesktop.Accounts / org.freedesktop.Accounts.User and has methods like SetRealName and SetIconFile. There are also a “bunch” of other methods for things like location, language, eMail, …
PS: you can also use libaccountsservice to interact with it without calling the DBus yourself. EG: void act_user_set_real_name (ActUser *user,
const char *real_name) and void act_user_set_icon_file (ActUser *user,
const char *icon_file) are exported from that library.
However, I don't know if K (or which version(s) of K) might be looking at this DBus service. So, if you really want to set up the K information, I'm afraid I don't know…
For what it's worth, you can also just let the user adjust it themself with
gnome-control-center user-accounts
Currently after I create a release branch, but when we have some time before we release, I sometimes open the entire branch for edit and then lock all files in order to prevent anybody from modifying anything during "code-freeze" period in the release branch.
Is there a better way? Doing it my current way seems possibly like an incorrect use of the lock feature, is there a better way to keep somebody from checking in code without using branches. I though of P4 protect but I am not the admin on this perforce instance, and also dealing with the protect file at potentially 100s of lines would get cumbersome as well.
Any ideas?
I'm doing this all the time as a builds engineer. I use 'p4 protect' to restrict everyone's access to the trees to read-only:
super group everyone * -//depot/project/branch/...
read group everyone * //depot/project/branch/...
super user me * //depot/project/branch/...
The first line closes all permissions for all users to the branch (assuming that the group 'everyone' is defined properly.)
The second line re-establishes read permissions for everyone.
The last line re-establishes all permissions to just me.
The way to do this in modern Perforce is to use streams -- named branches that update in place on your local system, and can have permissions applied to encourage you to do the right thing when merging and copying between streams.
You can optionally restrict a stream so only the stream owner can check in (and you can lock the stream so no one but the owner can edit its properties). See http://www.perforce.com/perforce/doc.current/manuals/p4guide/chapter.codelines.html#codelines.streams
p4 protect is definitely the better way to go - it's what it is there for. I would strongly recommend you put all your users into groups, and only ever use groups in your protections table - much easier to manage.
You can protect at any level of granularity you like, so is not unwieldy. Note also that the 2008.1 server release has a new protect feature that allows you to specify what you can do in a slightly different way. Change note:
#152278 **
'p4 protect' now allows specification of permission 'rights'.
Previously, 'p4 protect' only allowed using permission levels
which include the specified access (ie 'read') and also all
of its lesser permissions (ie 'read' = 'read' + 'list').
Permission rights make it possible to deny individual rights
without having to re-grant lesser rights. The new
permission rights are '=read', '=branch', '=open',
and '=write'. This functionality was previously undocumented,
and is now fully supported for 2008.1
If you really have an issue with having to be an admin to lock & unlock this, then you should take a look at the "group owner" feature introduced in 2007.3. This will let a non-super user to be able to add & remove people from a group. So combine that with the protections table. I.e. get site admin to set up the protections table, and restrict rights to a group named "Rel 1.0 Authorised", and make you the group owner. You can then add and remove users (or subgroups) from that group to control access.
The trigger option is a possibility, but you still need to be an admin to set up the trigger in the first place. You could also affect performance of all submissions, which is something to look out for. But the main issue with triggers is that you would be using them to emulate a built in feature designed for that purpose - i.e. protections table. And, if you wanted to be safe, you would still need to find some way of preventing anyone else modifying the reference file. It just seems like a lot of work to emulate an existing feature.
As a slight addition to one of the other answers. First set up a group "everyone" which has all users in it. Then add this to p4 protect
write group everyone * -//depot/project/1.0/...
read group everyone * //depot/project/1.0/...
write group 1.0 * //depot/project/1.0/...
This will allow you to create a group "1.0" into which you can add any users who are allowed write access.
If you are using server 2008.1 you can do this.
=write group everyone * -//depot/project/1.0/...
write group 1.0 * //depot/project/1.0/...
The first line removes only the write access ( not read and list ) from the group everyone.
P4 protect is probably the right answer for most people as explained in other answers.
However in my organization I can't be the admin so way of doing this is to have a trigger script in perforce that reads a text file that non-admins have write access to and check whether branch appears on the list.
This way admin access like p4 protect would need is not needed.