I have created my default group in bPermissions and the players that have the default rank can't build, I can't figure out why. I have even added the permission node "bpermissions.build". Here is the groups.yml:
default: default
groups:
default:
permissions:
- bpermissions.build
- essentials.afk
- essentials.afk.auto
- essentials.back
- essentials.home
- essentials.sethome
- essentials.spawn
- essentials.suicide
- mineconomy.balance.check
- mineconomy.bank.account.balance
- plotme.limit.1
- plotme.use.add
- plotme.use.auto
- plotme.use.buy
- plotme.use.protect
- plotme.use.remove
- warptastic.makesign
- warptastic.warp
groups: []
Please Help!
Try using the permission essentials.build
Your bpermissions.build is lowercase... Did you try uppercase?
As in: bPermissions.build
It's not the spawn area they're trying to build in, is it?
For bPermissions, you have to use the groups.yml in plugins/bPermissions/world-name, don't forget to set the other worlds to mirror the original world (same permissions for Nether and what not).
If that's the one you're using: are you SURE there isn't an issue with bPermissions and Essentials butting heads? Often mods won't work properly or certain functions fail to work due to them fighting.
On a side note, is there a reason you don't have the meta/priorities? It doesn't really matter right this second since you only have one group in this example, but add it if you plan on creating other groups like Mods and Admins or w/e.
I didn't need a permission for being able to build, it was enabled to all players by default o.o So I'm assuming that it's Essential permissions making it up or something xD If you want the building ability to be false for bPermissions, you'll have to tell it to be false.
Related
I have an aws managed node group that is acting unexpectedly when I set both desired size and minimum size to 0. I would expect that the managed node group would not have any nodes to start with, but that once I attempt to schedule a pod using a nodeSelector with the label eks.amazonaws.com/nodegroup: my-node-group-name, the cluster-autoscaler would set the desired size for the managed node group to 1, and a node would be booted.
However, the cluster-autoscaler logs indicate that the pending pod does not trigger a scale up because it wouldn't be schedulable: pod didn't trigger scale-up (it wouldn't fit if a new node is added). When I go set desired size to 1 in the managed node group manually however, the pod is scheduled successfully, so I know the nodeSelector works fine.
I thought this might be a labelling issue, as described here: , but I have the labels on my managed node groups set to be auto-discoverable.
spec:
containers:
- command:
- ./cluster-autoscaler
- --cloud-provider=aws
- --namespace=kube-system
- --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster-name
- --balance-similar-node-groups=true
- --expander=least-waste
- --logtostderr=true
- --skip-nodes-with-local-storage=false
- --skip-nodes-with-system-pods=false
- --stderrthreshold=info
- --v=4
I have set the same labels on the autoscaling group:
Key Value Tag new instances
eks:cluster-name my-cluster-name Yes
eks:nodegroup-name my-node-group-name Yes
k8s.io/cluster-autoscaler/enabled true Yes
k8s.io/cluster-autoscaler/my-cluster-name owned Yes
kubernetes.io/cluster/my-cluster-name owned Yes
Am I missing something? Or is this expected behavior for setting desired size to 0?
Ugh, it turns out this is just an aws incompatibility with the cluster-autoscaler that they don't tell you about. You can scale your managed node group down to zero, but without a workaround, you can't scale it back up.
For the cluster-autoscaler to scale up a node group from 0, it constructs a pseudo node based on the nodegroup specifications, in this case the aws autoscaling group. For the cluster-autoscaler to know what labels to put on that pseudo node to check if it would allow a pod to be scheduled, you need to add a specific tag to the nodegroup.
Sadly, aws does not add this tag to the autoscaling group for you, and also does not propagate tags from the managed node group to the autoscaling group. The only way to make this work is to go add the tag to the autoscaling group yourself after it was created by the managed node group. The issue is tracked here.
EKS now supports this with Cluster Autoscaler. https://realz.medium.com/reduce-amazon-eks-cost-by-scaling-node-groups-to-zero-41dce9db50ef
Using:
- Minecraft 1.7.10
- Forge 10.13.4.1614
- [Mod] Dr. Zhark's Mo Creatures (not enough rep to post link)
- [Mod] Realistic World Generator (RWG) 2
- [Mod] Dr. Zhark's Custom mob Spawner (CMS) (not enough rep to post link)
I attempted to modify the config files in the .minecraft folder to add all of the RWG Biomes to the acceptable spawn locations for the MoCreatures mod via CMS. I modified the EntityBiomeGroups.cfg file found at
C:...\AppData\Roaming.minecraft\config\CustomSpawner\overworld
And just for an example of the code used in the file:
S:MOC_MEDIUMFISH_DEFAULT <RWG|rwg_oceanIce:RWG|rwg_oceanCold:RWG|rwg_oceanTemperate:RWG|rwg_oceanHot:RWG|rwg_oceanWet:RWG|rwg_oceanOasis:MC|Swampland:MC|MushroomIslandShore:MC|Beach:MC|Stone Beach:MC|Cold Beach:MC|Swampland M>
After modifying the file, and checking multiple times to ensure that everything was typed in correctly, I received this error while attempting to load any minecraft world:
Description: Exception in server tick loop
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1954)
at drzhark.customspawner.utils.CMSUtils.parseName(CMSUtils.java:63)
at drzhark.customspawner.environment.EnvironmentSettings.populateSpawnBiomes(EnvironmentSettings.java:732)
at drzhark.customspawner.environment.EnvironmentSettings.updateSettings(EnvironmentSettings.java:259)
at drzhark.customspawner.utils.CMSUtils.addWorldEnvironment(CMSUtils.java:128)
at drzhark.customspawner.EventHooks.onWorldLoad(EventHooks.java:175)
at cpw.mods.fml.common.eventhandler.ASMEventHandler_156_EventHooks_onWorldLoad_Load.invoke(.dynamic)
at cpw.mods.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:54)
at cpw.mods.fml.common.eventhandler.EventBus.post(EventBus.java:140)
at net.minecraft.server.integrated.IntegratedServer.func_71247_a(IntegratedServer.java:73)
at net.minecraft.server.integrated.IntegratedServer.func_71197_b(IntegratedServer.java:92)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:387)
at net.minecraft.server.MinecraftServer$2.run(MinecraftServer.java:685)
I do not understand this completely. Does it help me find where the error is? Can anybody read this and tell me where I can find it? I'm at a loss here.
May be this mod download is error,
you try reinstall this mod - download here
I'm trying to figure out how to configure SLURM so that a user is required to specify --account when using the SLURM commands (salloc, sbatch, srun). Effectively I want to disable the default account behavior.
Has anyone out there found a simple way to do this?
I had the same requirement to force users to specify accounts and, after finding several ways to fulfill it with slurm, I decided to revive this post with the shortest/easiest solution.
The slurm lua submit plugin sees the job description before the default account is applied. Hence, you can install the slurm-lua package, add "JobSubmitPlugins=lua" to the slurm.conf, restart the slurmctld, and directly test against whether the account was defined via the job_submit.lua script (create the script wherever you keep your slurm.conf; typically in /etc/slurm/):
-- /etc/slurm/job_submit.lua to reject jobs with no account specified
function slurm_job_submit(job_desc, part_list, submit_uid)
if job_desc.account == nil then
slurm.log_error("User %s did not specify an account.", job_desc.user_id)
slurm.log_user("You must specify an account!")
return slurm.ERROR
end
return slurm.SUCCESS
end
function slurm_job_modify(job_desc, job_rec, part_list, modify_uid)
return slurm.SUCCESS
end
return slurm.SUCCESS
Errors resulting from not specifying an account appear as follows:
# srun --pty bash
srun: error: You must specify an account!
srun: error: Unable to allocate resources: Unspecified error
# sbatch submit.slurm
sbatch: error: You must specify an account!
sbatch: error: Batch job submission failed: Unspecified error
These errors are also printed out to the slurmctld log so that you know what the resource allocation issue was for the particular job:
[2017-09-12T08:32:00.697] error: job_submit.lua: User 0 did not specify an account.
[2017-09-12T08:32:00.697] _slurm_rpc_submit_batch_job: Unspecified error
As an addendum, the Slurm Submit Plugins Guide is only moderately useful and you will probably be much better off simply examining the Lua job_submit plugin implementation for guidance.
One option is to set the AccountingStorageEnforce parameter to associations in slurm.conf.
AccountingStorageEnforce
This controls what level of association-based enforcement to impose on job submissions. Valid options are any combination of
associations, limits, nojobs, nosteps, qos, safe, and wckeys, or all
for all things (expect nojobs and nosteps, they must be requested as
well).
By enforcing Associations no new job is allowed to run unless a corresponding association exists in the system. If limits are enforced
users can be limited by association to whatever job size or run time
limits are defined.
Then, with the sacctmgr command, make sure the default account has no access to the defined partitions. Effectively, the users will be denied submission if they do not specify a valid account.
Another option is to write a custom submission plugin, which you can write in Lua. In that script, you can check whether the --account parameter was set and deny submission with a custom message if it was not.
I am running a very simple query and trying to extract the results to a text file. The entire query is essentially what is below, I am selecting everything from one single table with one piece of where criteria which is limiting the data to one month's worth. After it has extracted around 1.2 gig this error shows up. Is there any way that I can work around this other than extracting smaller date ranges? I am trying to pull a couple of years worth of data so if I can only get it a few days at a time it will take a lot of manual work.
I am currently using the free trial of a DB2 query tool - Razor SQL if that makes a difference, I can probably purchase different software if it would help. I am trying to get IBM's tool but for some reason it freezes during the download so I am still working on that. I have searched about this error but everything I see seems much more complex than what I am doing and I can't tell if it applies or not. Thanks in advance.
select *
from MyTable
where date_col between date '2014-01-01' and date '2014-01-31'
I stumbled at this error too, found out it is related to db2jcc.jar (type 4) driver.
Excerpt: If there are no items in the result set left (or to begin with), the Result set is closed automatically and therefore the Exception. Suggestion is to handle it in the application, perhaps in my case, I started checking if(rs.next()) but otherwise, there is a work around. Check out the source link below for how you can set some properties to Data source and avoid exception.
Source :
"Invalid operation: result set is closed" error with Data Server Driver for JDBC
In my case, i missed some properties in WAS, after add allowNextOnExhaustedResultSet the issue is fixed.
1.Log in to the WebSphere Application Server administration console.
2.Select Resources > JDBC > Data sources > Application Center DataSource name > Custom properties and click New.
3.In the Name field, enter allowNextOnExhaustedResultSet.
4.In the Value field, type 1.
5.Change the type to java.lang.Integer.
6.Click OK.
Sometimes you need also check whether resultSetHoldability properties exists. Details refer to here.
I encountered this failure also when ugrading from JDBC Type 2 driver (db2java.zip) JDBC type 4 driver (db2jcc4.jar)
Statement statement = results.getStatement();
if (statement != null)
{
connection = statement.getConnection(); // ** failed here
statement.close();
}
Solution was to check if the statement is closed or not as follows.
Changed to:
Statement statement = results.getStatement();
if (statement != null && !statement.isClosed()) {
{
connection = statement.getConnection();
statement.close();
}
Creating property bellow with type Integer it's worked for me:
allowNextOnExhaustedResultSet:
I had the same issue on WAS 7 so i had to add and change few this on Admin Console.
This TeamWorksRuntimeException exception should be fixed by applying APAR JR50863 which is available on top of BPM V8.5.5 or included on BPM V8.5 refresh pack 6.
For the case that the APAR does not solve the problem, try following workaround:
Log in to the WebSphere Application Server admin console
Select Resources > JDBC > Data sources > DataSource name (TeamWorksDB) > Custom properties and click New
In the Name field, enter downgradeHoldCursorsUnderXa
In the Value field, type true
Change the type to java.lang.Boolean
Click OK to save your changes
Select custom property resultSetHoldability
In the Value field, type 1
Click OK to save your changes
Source of the Answer : https://developer.ibm.com/answers/questions/194821/invalid-operation-result-set-is-closed-errorcode-4/
Restarting the app may fix the problem if connection pool lost session to Db2. If using Tomcat then connection pool property of 'testonBorrow' may reestablish the connection to Db2.
I'm new cloudbees user, I've succeeded in building my war file but I can't deploy it because when a I'm going to use Deploy Now option, putting my application ID claxon/claxon I always get the same error:
**"hudson.util.IOException2: Server.InternalError - Expected Application ID format: account/appname > claxon/"**
this is the log..
hudson.util.IOException2: Server.InternalError - Expected Application ID format: account/appname > claxon/
at com.cloudbees.plugins.deployer.deployables.Deployable.deployFile(Deployable.java:152)
at com.cloudbees.plugins.deployer.DeployNowRunAction$Deployer.perform(DeployNowRunAction.java:639)
at com.cloudbees.plugins.deployer.DeployNowRunAction.run(DeployNowRunAction.java:484)
at com.cloudbees.plugins.deployer.DeployNowTask$ExecutableImpl.run(DeployNowTask.java:157)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:236)
Caused by: com.cloudbees.api.BeesClientException: Server.InternalError - Expected Application ID format: account/appname > claxon/
at com.cloudbees.api.BeesClient.readResponse(BeesClient.java:850)
at com.cloudbees.api.BeesClient.applicationDeployArchive(BeesClient.java:435)
at com.cloudbees.plugins.deployer.deployables.Deployable.deployFile(Deployable.java:124)
... 5 more
Duration: 4.1 sec
Finished: FAILURE
Anybody can help me?.
Don't put the claxon/ the account is sorted for you when you choose the account from the account drop down. just put the id part.
If you expand the help text you will see that it says not to prefix:
Note: I used my superuser rights to capture this screenshot... the only bit that might be confidential is your account name, which you had already exposed via the original question.