I am new to
Conga Composer
and don't have any knowledge of using Word Template to create for below condition. I am trying to get below solution to print text if have 2 different value in one Field.
Please help me out to find solution.
for
Eg:
Conga Composer Release 7
Conga Composer Release 7
Conga Composer Release 8
Conga Composer Release 7
Conga Composer Release 9
if found "Conga Composer Release 7 & 8" Text must populate as "It's Cat 1" if Conga Composer Release 8 & 9 "It's Cat 2"
Below image is my rough logic :
Related
I am following the tutorial on
Center for High Throughput Computing and Introduction to Configuration in the HTCondor website to set up a Partitionable slot. Before any configuration I run
condor_status
and get the following output.
I update the file 00-minicondor in /etc/condor/config.d by adding the following lines at the end of the file.
NUM_SLOTS = 1
NUM_SLOTS_TYPE_1 = 1
SLOT_TYPE_1 = cpus=4
SLOT_TYPE_1_PARTITIONABLE = TRUE
and reconfigure
sudo condor_reconfig
Now with
condor_status
I get this output as expected. Now, I run the following command to check everything is fine
condor_status -af Name Slotype Cpus
and find slot1#ip-172-31-54-214.ec2.internal undefined 1 instead of slot1#ip-172-31-54-214.ec2.internal Partitionable 4 61295 that is what I would expect. Moreover, when I try to summit a job that asks for more than 1 cpu it does not allocate space for it (It stays waiting forever) as it should.
I don't know if I made some mistake during the installation process or what could be happening. I would really appreciate any help!
EXTRA INFO: If it can be of any help have have installed HTCondor with the command
curl -fsSL https://get.htcondor.org | sudo /bin/bash -s – –no-dry-run
on Ubuntu 18.04 running on an old p2.xlarge instance (it has 4 cores).
UPDATE: After rebooting the whole thing it seems to be working. I can now send jobs with different CPUs requests and it will start them properly.
The only issue I would say persists is that Memory allocation is not showing properly, for example:
But in reality it is allocating enough memory for the job (in this case around 12 GB).
If I run again
condor_status -af Name Slotype Cpus
I still get something I am not supposed to
But at least it is showing the correct number of CPUs (even if it just says undefined).
What is the output of condor_q -better when the job is idle?
My workstation has Ubuntu OS 18.04. I use the ldapcpp library from OpenLDAP-2.4.47 in my Qt project for authorization on MS ActiveDirectory server. The code works fine.
LDAPControlSet* ctrls=new LDAPControlSet;
ctrls->add(LDAPCtrl(LDAP_CONTROL_MANAGEDSAIT));
cons->setServerControls(ctrls);
LDAPConnection *lc=new LDAPConnection("dc.mydomen.local",389);
lc->setConstraints(cons);
lc->bind("CN=username,OU=Programmer,OU=IVO,DC=mydomen,DC=local", "password",cons);
My workstation is in the domain.
username#kubuntuit01:~$ sudo net ads testjoin
Join is OK
username#kubuntuit01:~$ sudo net ads keytab list
Vno Type Principal
2 des-cbc-crc HOST/kubuntuit01.mydomen.local#MYDOMEN.LOCAL
2 des-cbc-crc HOST/KUBUNTUIT01#MYDOMEN.LOCAL
2 des-cbc-md5 HOST/kubuntuit01.mydomen.local#MYDOMEN.LOCAL
2 des-cbc-md5 HOST/KUBUNTUIT01#MYDOMEN.LOCAL
2 aes128-cts-hmac-sha1-96 HOST/kubuntuit01.mydomen.local#MYDOMEN.LOCAL
2 aes128-cts-hmac-sha1-96 HOST/KUBUNTUIT01#MYDOMEN.LOCAL
2 aes256-cts-hmac-sha1-96 HOST/kubuntuit01.mydomen.local#MYDOMEN.LOCAL
2 aes256-cts-hmac-sha1-96 HOST/KUBUNTUIT01#MYDOMEN.LOCAL
2 arcfour-hmac-md5 HOST/kubuntuit01.mydomen.local#MYDOMEN.LOCAL
2 arcfour-hmac-md5 HOST/KUBUNTUIT01#MYDOMEN.LOCAL
But i cannot connect using the saslbind method using the code:
LDAPAsynConnection * sas;
sas = new LDAPAsynConnection();
sas->init("dc.mydomen.local",389);
sas->saslBind("KERBEROS","uid=HOST/KUBUNTUIT01,cn=VIVEYA.LOCAL,cn=gssapi,cn=auth",cons);
or
sas->saslBind("GSSAPI","uid=HOST/KUBUNTUIT01,cn=VIVEYA.LOCAL,cn=gssapi,cn=auth",cons);
In debug mode in the debugger, the message string contains the text: "80090308: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 57, v1db1". I tried different authorization options, I don’t know what to try next.
thank
got this error while I tried to run my very first grail app..:(
enter image description heregot this error while I tried to run my very first grail app..:(
Some steps you can follow to resolve...
Check the JDK and Grails, both need to be same 32 bit or both need to be same 64 bit
Execute this on command prompt: java -Xmx2048m -Xms256m
Then rebuild and run app
The initial memory allocated to your JVM is bigger than the maximum JVM memory size you allocated via your -Xmx parameter.
see What are the Xms and Xmx parameters when starting JVMs?
I have two elasticsearch cluster - cluster1 (version 2.4.x) and cluster2 (version 5.1.1). I am feeding live data to these two cluster from logstash (version 5.x) to achieve a stable state between cluster 1 and 2. The data is now in sync between these two cluster but the cluster 2's index size is almost double when compared to cluster 1's index size. Below is an example:
ES Version health status index pri rep docs.count docs.deleted store.size pri.store.size
2.4.x Old_Cluster green open index1-08 5 1 6520824 0 5.3gb 2.6gb
5.1.1 New_Cluster green open index2-08 5 1 6520824 0 9.3gb 4.6gb
As you can see above the docs.count is same between these two indexes but the size of the index2-08 is double the size of index1-08. Both clusters have similar configuration with respect to their versions.
The logstash (version 5.x) creates these two indexes using default mappings. This is lowering kibana's search capability. I am new to ELK thus am not sure if this something expected.
Can anyone please take a look and provide any suggestions on what might be the reason for this behaviour?
(EDIT: per the first answer below the current "trick" seems to be using an Atom processor. But I hope some gdb guru can answer if this is a fundamental limitation, or whether there adding support for other processors is on the roadmap?)
Reverse execution seems to be working in my environment: I can reverse-continue, see a plausible record log, and move around within it:
(gdb) start
...Temporary breakpoint 5 at 0x8048460: file bang.cpp, line 13.
Starting program: /home/thomasg/temp/./bang
Temporary breakpoint 5, main () at bang.cpp:13
13 f(1000);
(gdb) record
(gdb) continue
Continuing.
Breakpoint 3, f (d=900) at bang.cpp:5
5 if(d) {
(gdb) info record
Active record target: record-full
Record mode:
Lowest recorded instruction number is 1.
Highest recorded instruction number is 1005.
Log contains 1005 instructions.
Max logged instructions is 200000.
(gdb) reverse-continue
Continuing.
Breakpoint 3, f (d=901) at bang.cpp:5
5 if(d) {
(gdb) record goto end
Go forward to insn number 1005
#0 f (d=900) at bang.cpp:5
5 if(d) {
However the instruction and function histories aren't available:
(gdb) record instruction-history
You can't do that when your target is `record-full'
(gdb) record function-call-history
You can't do that when your target is `record-full'
And the only target type available is full, the other documented type "btrace" fails with "Target does not support branch tracing."
So quite possibly it just isn't supported for this target, but as it's a mainstream modern one (gdb 7.6.1-ubuntu, on amd64 Linux Mint "Petra" running an "Intel(R) Core(TM) i5-3570") I'm hoping that I've overlooked a crucial step or config?
It seems that there is no other solution except a CPU that supports it.
More precisely, your kernel has to support Intel Processor Tracing (Intel PT). This can be checked in Linux with:
grep intel_pt /proc/cpuinfo
See also: https://unix.stackexchange.com/questions/43539/what-do-the-flags-in-proc-cpuinfo-mean
The commands only works in record btrace mode.
In the GDB source commit beab5d9, it is nat/linux-btrace.c:kernel_supports_pt that checks if we can enter btrace. The following checks are carried out:
check if /sys/bus/event_source/devices/intel_pt/type exists and read the type
do a syscall (SYS_perf_event_open, &attr, child, -1, -1, 0); with the read type, and see if it returns >=0. TODO: why not use the C wrapper?
The first check fails for me: the file does not exist.
Kernel side
cd into the kernel 4.1 source and:
git grep '"intel_pt"'
we find arch/x86/kernel/cpu/perf_event_intel_pt.c which sets up that file. In particular, it does:
if (!test_cpu_cap(&boot_cpu_data, X86_FEATURE_INTEL_PT))
goto fail;
so intel_pt is a pre-requisite.
How I've found kernel_supports_pt
First grep for:
git grep 'Target does not support branch tracing.'
which leads us to btrace.c:btrace_enable. After a quick debug with:
gdb -q -ex start -ex 'b btrace_enable' -ex c --args /home/ciro/git/binutils-gdb/install/bin/gdb --batch -ex start -ex 'record btrace' ./hello_world.out
Virtual box does not support it either: Extract execution log from gdb record in a VirtualBox VM
Intel SDE
Intel SDE 7.21 already has this CPU feature, checked with:
./sde64 -- cpuid | grep 'Intel processor trace'
But I'm not sure if the Linux kernel can be run on it: https://superuser.com/questions/950992/how-to-run-the-linux-kernel-on-intel-software-development-emulator-sde
Other GDB methods
More generic questions, with less efficient software solutions:
call graph: List of all function calls made in an application
instruction trace: Displaying each assembly instruction executed in gdb
At least a partial answer (for the "am I doing it wrong" aspect) - from gdb-7.6.50.20140108/gdb/NEWS
* A new record target "record-btrace" has been added. The new target
uses hardware support to record the control-flow of a process. It
does not support replaying the execution, but it implements the
below new commands for investigating the recorded execution log.
This new recording method can be enabled using:
record btrace
The "record-btrace" target is only available on Intel Atom processors
and requires a Linux kernel 2.6.32 or later.
* Two new commands have been added for record/replay to give information
about the recorded execution without having to replay the execution.
The commands are only supported by "record btrace".
record instruction-history prints the execution history at
instruction granularity
record function-call-history prints the execution history at
function granularity
It's not often that I envy the owner of an Atom processor ;-)
I'll edit the question to refocus upon the question of workarounds or plans for future support.