Is it possible to create a linux users group programmatically? - c++

I'd like to know if it is possibile to create a linux users group (and also add one or more users to it) via c++ code
For the code I'm working on I need to create a group with specific privileges and to add the users that want to run my software to it.
I already created the group manually and everithing works as expected.
Now, the simplest solution to my problem would be to add to the software documentation the steps needed to create the group and to add users to it. But I'd like my software to do it automatically, if possible.
I hope that my question is clear enough. If not, please let me know.

Related

Release pipeline design idea

I want to build a release pipeline having two stages Stage1 and stage2. In each stages I need to deploy multiple customers. I am getting the customer information from the JSON file using PowerShell script. Below are some of the questions that I need to solve
The above JSON file needs to be created dynamically using input from the customer. How to get input from the customer?.
Also planning to create Variable groups to hold the constant data needed for each customer. DO I need to create a separate variable group for each customer?
Regarding your first question:
It is possible to allow variables to be provided by users when they launch the Release job. As an alternative, you might consider creating an app in PowerApps and use the Azure DevOps connector that PowerApps provide to trigger the job. This will allow you to create a more user friendly front-end.
Regarding your second question:
You don't necessarily need to, however you'll likely find it much easier if you use separate variable groups per customer.

django: give some users less permissions

The app is installed at several customers and each installation has several groups and a lot of users.
In the past every user was allowed to use the basic feature BasicFeature.
A small new group ("RestrictedUsage") of users should not have the permission to have this BasicFeature.
Our current automated update idea looks like this:
Create new permission UseBasicFeature
Give all existing groups the new permission.
Create the new group "RestrictedUsage"
Since we have several customers, we need an automated way to handle this.
The above solution does should work, but I don't like it.
I don't like it because installations which don't have a "RestrictedUsage" group need to be modified. Otherwise the users would not be allowed to use BasicFeature (which they use since ages).
Has anybody see better way?

How to create an independent Fundraising Page in CiviCRM

I am new to CiviCRM and need to create a fundraising page. I am using CiviCRM with Drupal7. As per my limited knowledge of CiviCRM, Individual users can create their Personal Campaign Pages to support different Events. But is it possible for users to create an entirely independent Fundraising page that allows them to fundraise for a particular cause and collect donations? Something like "START YOUR CAMPAIGN" tab on http://my.charitywater.org website. if Yes, How is that done?
Any Help Much Appreciated!
Thanks in Advance!
One solution is to create a "normal" contribution page that is the cause you want to collect money for, and enable the personal campaign pages on it.
You can make this "root" contribution page as generic and abstract as you want and let your supporters create their fundraising pages how they want it.
Not really. You probably want them to be able to create a full Contribution page for that. If you are offering this to front end users you probably want to make a custom interface for it using Drupal and automatically create the contribution page in the background using the API etc. Other people have done this type of thing in the past but I not sure if any that work is public. I suggest you ask on the CiviCRM forums.

How can I get the list of user accounts that Windows presents on the Log-On screen?

I'm using NetQueryDisplayInformation (I've already tried the NetUserEnum function) to get the set of user accounts on the local machine. I can get all the accounts this way - but I only want the accounts associated with actual human beings, and not, for example, hidden accounts used for software updates.
After reading the MSDN documentation on the relevant structures and similar Stack questions, I see nothing that can allow me to filter to just the accounts that I need.
Ideally, someone will have a simple and reliable solution that:
Doesn't involve using undocumented registry entries
Doesn't rely on enumerating user folders on disk
I'm not going to try to build an exhaustive list of non-real-user accounts
For technical reasons, WMI is not an option
Any ideas?
[Much later]
Got the answer, but not here - just enumerate the groups for each user. "Real human" accounts will be a member of one or more of Administrator, Power User, User, Guest.
You may be able to use the NetUserEnum function. It should return a list of all the user accounts on the system. I've not had to use this function personally so I can't provide any spectacular code examples, but the MSDN information sounds like what you are looking for.
You can use NetQueryDisplayInformation API, combine with bitwise check on user info flag.
I have exactly the same requirements, so I cook sample code (modified from MSDN GROUP query).
The user flags I used are:
UF_NORMAL_ACCOUNT
UF_ACCOUNTDISABLE
UF_PASSWD_NOTREQD ---> this ensure we get Human account, Human account always requires password.
working code at: http://www.cceye.com/list-system-normal-user-account-only/

Two-staged approval process for wiki articles

I'm trying to configure a wiki to allow a two staged approval process. The basic work flow requires something like:
A group of users submits a short form
After admin approval, a larger form becomes available to the group
The group submits the larger form
After admin approval, the page (filled by the form) becomes public
I've been looking at TikiWiki and MediaWiki for a while trying to configure each to get even close to this model, but I'm having some problems.
With TikiWiki, it seems like the approval stage should be a transition, either changing the group permissions to allow access to a new tracker or changing the form category to close one form and open the other, but I haven't been able to nail down the permissions for that configuration.
With MediaWiki, the main problem seems to be that the back-end was not made to have complex permissions. I've been using SMWHalo along with SemanticForms to construct this, but I can't find anything like Tikiwiki's transitions for changing the permissions for either the group or the form automatically.
I'm a bit new to Wiki development and I know that there are a lot of options for wiki frameworks, so I'm asking for suggestions for a good work flow for this product. My goal is to only start actually touching the framework code to make the final adjustments and not to start off modifying an already well developed code base.
You should really ask yourself why you want this and why you want this in a wiki.
A Wiki's main advantage is being quick and easy and thus encouraging to the user. Adding approval stages will discourage users to participate. The hardest part in any wiki is not preventing vandalism or false information. The hardest part is to encourage participation.
If you really need a difficult approval workflow you might want to look at CMS systems. AFAIK typo3 has something like this built in.
If really you want to go with a wiki and an approval process, for DokuWiki you could have a look a the publish plugin: http://www.dokuwiki.org/plugin:publish
The FlaggedRevs extension to MediaWiki adds a basic permissions workflow:
http://www.mediawiki.org/wiki/Extension:FlaggedRevs
However, it's geared more at controlling changes to existing pages, not adding entirely new ones. You could set it up to create new pages as drafts and defaulting the public view to show only approved versions, but it sounds like you want to hide unapproved versions entirely, which would require some extra hacking (and, as Andreas says, kind of defeats the point of a wiki in the first place).