I have run this code:
sudo -u ejabberd /usr/sbin/ejabberdctl send_direct_invitation mt75_1 conference.msg.hajmobility.my none none msg_din#msg.hajmobility.my:msg_apool#msg.hajmobility.my
It works for the first time.
But when i want to add the same user into another MUC room using the same code its not working.
I don't see that problem in ejabberd 18.03
I create two rooms, then invite two users to them. One user is online and receives the invitations immediately and can join them. The other invited user is offline, when he logins, he receives both invitations and can join the rooms too.
$ ejabberdctl send_direct_invitation room1 conference.localhost none none user3#localhost:user4#localhost
$ ejabberdctl send_direct_invitation room2 conference.localhost none none user3#localhost:user4#localhost
Related
I tried openshift redhat k8s distro and now there are 2 projects that i need to delete. I can only login as user 'erjcan', this is my primary acc and it seems not to be allowed to do admin actions.
The 'delete button' is inactive in gui console, i tried to create a role for myself but can't.
I tried to create admin-like role and assume it as a user, but it is not allowed either.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: all-stuff
namespace: erjcan-stage
rules:
- apiGroups:
- ''
resources:
- '*'
verbs:
- '*'
This code above gives me RBAC not allowed error:
An error occurred
roles.rbac.authorization.k8s.io "all-stuff" is forbidden: user "erjcan"
(groups=["system:authenticated:oauth" "system:authenticated"]) is
attempting to grant RBAC permissions
not currently held: {APIGroups:[""], Resources:["*"],
Verbs:["*"]}
I tried to delete via cli, but i can only login as erjcan user.
Logged into "https://api.sandbox-m2.ll9k.p1.openshiftapps.com:6443" as "erjcan" using the token provided.
You have access to the following projects and can switch between them with 'oc project <projectname>':
erjcan-dev
* erjcan-stage
Using project "erjcan-stage".
bash-4.4 ~ $
bash-4.4 ~ $ oc delete project erjan-dev
Error from server (Forbidden): projects.project.openshift.io "erjan-dev" is forbidden: User "erjcan" cannot delete resource "projects" in API group "project.openshift.io" in the namespace "erjan-dev"
bash-4.4 ~ $ oc delete project erjcan-dev
Error from server (Forbidden): projects.project.openshift.io "erjcan-dev" is forbidden: User "erjcan" cannot delete resource "projects" in API group "project.openshift.io" in the namespace "erjcan-dev"
How to delete a project in redhat openshift gui console?
You appear to be talking about using Red Hat's developer sandbox. Which, indeed, does not allow you to delete projects. There's no way around that: RBAC is specifically set up to not allow you to create or delete projects.
You don't say why you need to delete the projects. They will go away eventually do to inactivity. But, if you just want a clean slate, or just need to remove what you have inside that project you do have permission to delete everything in the project (just not the project itself).
oc delete all --all will remove everything inside the current project. Obviously use that command with strict care: there is no confirmation or warning. (BTW, the first "all" is saying all types of objects: pods/deployments/routes/etc, the second --all is saying "yes, I'm deliberately not providing a filter or any other subset, I really mean delete all of the objects I'm specifying".
Similarly, the following two commands should clean up both of your projects. (Although they will still exist.)
oc delete all --all -n erjcan-stage
oc delete all --all -n erjcan-dev
I have two cluster nodes server1 and sever2 running on CENTOS7 and I configured DRBD. I have DRBD running on both servers and data is being replicated. The issue is when I perform a test failover the user and group ownership (mysql:mysql) are not consistent when mounted on server2 and this causes MySQL not to start untill the ownership is changed to mysql:msyql manually. please help. Anyone faced this error before?
/proc/drbd server1:
[root#sis1 ~]# cat /proc/drbd
version: 8.4.11-1 (api:1/proto:86-101)
GIT-hash: 66145a308421e9c124ec391a7848ac20203bb03c build by mockbuild#, 2020-04-05 02:58:18
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
ns:21101 nr:2070 dw:23171 dr:4377 al:8 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
/proc/drbd server2:
[root#sis2 ~]# cat /proc/drbd
version: 8.4.11-1 (api:1/proto:86-101)
GIT-hash: 66145a308421e9c124ec391a7848ac20203bb03c build by mockbuild#, 2020-04-05 02:58:18
0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
ns:2070 nr:21101 dw:23171 dr:2916 al:2 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
As was already determined from the comments in the original post, I suspect that the UID and GID of the mysql user on both host do not match. Thus after a failover the files are owned by the UID of the mysql user on node1, but not the mysql user on node2.
Making sure that the UID and GID of the mysql user (all users ideally) match on both host should avoid this issue.
Our goal is to change the “default permissions” as documented in https://docs.openshift.com/container-platform/3.6/admin_solutions/user_role_mgmt.html#leveraging-default-groups .
The groups system:authenticated , system:authenticated:oauth, system:unauthenticated
should not be able to access the API. One use case is: An ldap user who is not in the administrator group is not allowed to log into the web console. This is also how we test it.
Commands such as
oadm policy remove-cluster-role-from-user basic-user system:authenticated
oadm policy remove-cluster-role-from-user system:basic-user system:authenticated
return without error. However, we couldn’t see any effect, either. The output of oc get clusterrolebindings and oc get rolebindings remains the same, and our test user still can log on.
Are we trying the wrong commands? Or are further actions needed?
This worked:
oadm policy remove-cluster-role-from-group basic-user system:authenticated
So system:authenticated is a group, not a user. And it was the wrong command.
Thanks Red Hat Support.
Though - the cluster didn't work after running the above command, and
oadm policy remove-cluster-role-from-group basic-user system:unauthenticated
We had to revert it. I wonder if it was only the second command that wrought havoc. After nearly a week of downtime, though, the rest of the team isn't too keen on testing what happens if you only revoke basic-user from system:authenticated.
I cannot create a virtual machines in GCE.. While creating it is showing the error message, i have attached my screen-shot of error message.. i will briefly explain what i have done..
--> I have deleted my compute engine default service account from my service account list.. later i created new service account..
--> While creating virtual machines i selected newly created service account, vm creating was failed but the error shows the deleted service account id is not found under service account..
--> While creating vm's it is referring my deleted service account id..
Now what i need to do? Is there is any solution to reactivate my Compute Engine default service account..
Completely iam struck now i cannot create new vms and kubernetes.
To restore your google compute default service account, run the following gcloud command within your project:
gcloud services enable compute
In previous versions the command was known to be:
gcloud service-management enable compute.googleapis.com
As stated in this issue: https://issuetracker.google.com/issues/69612457
You can now "undelete" service accounts by doing a curl request as below:
curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" -H "Content-length: 0" "https://iam.googleapis.com/v1/projects/-/serviceAccounts/SERVICE_ACCOUNT_ID:undelete"
SERVICE_ACCOUNT_ID is the id of the account you want to recover
You can get a list of service accounts by running:
gcloud logging read "resource.type=service_account" --freshness=10y
Reference:
https://cloud.google.com/iam/docs/creating-managing-service-accounts#undeleting_a_service_account
There are two default service accounts and I am not sure which one you are referring to:
Google API service account, in your case it is called: 933144605699#cloudservices.gserviceaccount.com. It is a special service account. It is always created but never listed in gcloud or the web console. It is intended to be used by some of the internal Google processes on user's behalf. GKE may be one of the services that uses this account (I am not sure).
It is impossible to delete this account, the only thing you could do is to remove it from any roles on the project. By default it is an Editor. You can add it back any time.
Default service account: 933144605699-compute#developer.gserviceaccount.com. This is a normal service account, which you may delete.
In the error message you pasted there is a different service account name, is it the new one you created? If this is the case, you might only need to go to IAM settings on the web console and add your user to service account actor. Take a look at this manual page: https://cloud.google.com/compute/docs/access/iam#the_serviceaccountactor_role
First you need to find the removed SERVICE_ACCOUNT_ID. Using Logging advanced queries is:
resource.type = "service_account"
protoPayload.authorizationInfo.permission = "iam.serviceAccounts.delete"
Example here:
==> unique_id value is SERVICE_ACCOUNT_ID
Use the API provided by #sherief-el-feky :
curl -X POST -H "Authorization: Bearer $ (gcloud auth print-access-token)" -H "Content-length: 0" https://iam.googleapis.com/v1/projects/-/serviceAccounts/SERVICE_ACCOUNT_ID : undelete "
Logging advanced queries: https://cloud.google.com/logging/docs/view/advanced-queries
As of Feb 2022, use
gcloud beta iam service-accounts undelete <ACCOUNT ID>
ACCOUNT ID is the 21 digit unique id (uid) which last part of the deleted service account.
For example,
deleted:serviceAccount:abc-project#kubeflow-ml.iam.gserviceaccount.com?uid=123451234512345123451
uid is the last part of the above service account.
Attempting to set up Samba + OpenLDAP using nss_ldap.
After joining Windows7 to Samba stand alone PDC, I can not login with a domain account unless that account is also added to the /etc/passwd file.
I get: user in passdb, but getpwnam() fails!
Everything I've read points to an NSS_LDAP issue yet, getent passwd shows users perfectly fine and I am able to ssh into the same Linux host using a user account that is only in the LDAP database.
Additionally, if I crack open the /etc/passwd file and add a line for the user in question, I can then login.
I'm not using PAM. I added the two Windows7 registry updates required per the Samba.org site.
Software stack is as follows:
Samba 3.5.3
OpenLDAP 2.4.21
nss_ldap 264
Thoughts/suggestions?
--------------------------------- UPDATE ---------------------------------
Getting closer! My nsswitch.conf did have files ldap so I reversed the order (now ldap files) and something odd happen. Notice, before, I said I could login with SSH and getent passwd dumped users in both ldap and files. After making the nsswitch.conf change, ldap before files, simple commands like ls took a long time. Additionally I observed nss_ldap errors as follows:
ls: nss_ldap: could not search LDAP server - Server is unavailable
and
ls: nss_ldap: failed to bind to LDAP server ldap://tsrvr.example.corp: Invalid credentials
I commented out the rootbinddn line in ldap.conf and these errors went away and getent passwd immediately began working again. The order of the output changed also: ldap entries listed before files entries.
Still, though, my Windows7 client will not login to the domain and I continue to get the same Samba error message
User test in passdb, but getpwnam() fails!
In my smb.conf, I tried removing ldapsam:trusted = yes line and when I do, I get domain authentication errors.
I'm not using SSL/TLS with OpenLDAP and I have the SSL = no setting. I also have the ldap.secret file set. I'm running slapd under the root account. My rootbinddn, before commenting out, referenced an LDAP root user of uid=root,ou=Users,dc=example,dc=corp. root's userPassword using CRYPT matches the bindpw as well as the one in /etc/shadow.
Looking at LDAP log activity for when I get the Samba error, it appears as if LDAP is returning the correct result against a Samba query:
Jun 19 14:20:14 tsrvr slapd[3803]: conn=1025 op=15 SRCH base="dc=example,dc=corp" scope=2 deref=0 filter="(&(uid=test)(objectClass=sambaSamAccount))"
Jun 19 14:20:14 tsrvr slapd[3803]: conn=1025 op=15 SRCH attr=uid uidNumber gidNumber homeDirectory sambaPwdLastSet sambaPwdCanChange sambaPwdMustChange sambaLogonTime sambaLogoffTime
sambaKickoffTime cn sn displayName sambaHomeDrive sambaHomePath sambaLogonScript sambaProfilePath description sambaUserWorkstations sambaSID sambaPrimaryGroupSID sambaLMPassword sam
baNTPassword sambaDomainName objectClass sambaAcctFlags sambaMungedDial sambaBadPasswordCount sambaBadPasswordTime sambaPasswordHistory modifyTimestamp sambaLogonHours modifyTimestam
p uidNumber gidNumber homeDirectory loginShell gecos
Jun 19 14:20:14 tsrvr slapd[3803]: conn=1025 op=15 SEARCH RESULT tag=101 err=0 nentries=1 text=
Any other suggestions?
Much appreciated
Sounds like a problem with /etc/nsswitch.conf. Specifically, the passwd and group lines should refer to ldap before compat or file. Have you looked at this Samba wiki entry?
SOLVED!!!!!!!!!!!
I have a script that was starting Samba (NMBD, SMBD) as well as OpenLDAP (SLAPD). It's an RC script that reads configuration data from a file to determine, among other things, which processes are already running or if a dependent process fails to start, etc... Here is a snippet of the relevant part in the script. The last line copies a version of the nsswitch.conf into place that specifies to use LDAP lookups.
while [ $i -lt $MAXPROCS ];
do
PID=${PROC[$i]}
StartProc $PID
if test $? != 0; then
echo "!!! Aborting Any Remaining Start-up Processes !!!"
exit 1
fi
i=$(($i+1))
done
cp /etc/rc.d/pozix/nsswitch.conf.ldap /etc/nsswitch.conf
And upon shutdown I was doing the following; notice I copy a nsswitch.conf file that has "noldap" entries in it.
while [ $i -lt $MAXPROCS ];
do
PID=${PROC[$i]}
StopProc $PID
i=$(($i+1))
done
cp /etc/rc.d/pozix/nsswitch.conf.noldap /etc/nsswitch.conf
It turns out that in the start-up scenario, samba wants the nsswtich.conf content to have the ldap entries there prior to invocation. Here is what I did to fix my issues:
cp /etc/rc.d/pozix/nsswitch.conf.ldap /etc/nsswitch.conf
while [ $i -lt $MAXPROCS ];
do
PID=${PROC[$i]}
StartProc $PID
if test $? != 0; then
cp /etc/rc.d/pozix/nsswitch.conf.noldap /etc/nsswitch.conf
echo "!!! Aborting Any Remaining Start-up Processes !!!"
exit 1
fi
i=$(($i+1))
done
In summary, it appears that how you start SMBD is just as important as when you start it. If you start SMBD when nsswitch.conf has no LDAP entries, you get a version of smbd running linked to nss_ldap.so thinking it should only rely upon /etc/passwd (if that is all that is in the nsswitch.conf file) and changing the nsswitch.conf contents after SMBD is running has no effect.
Hope this helps other system builders....