When getting list of views in IBM Rational ClearTeam Explorer, it reports the error message"CRMAP7007: Error reading local file area registry." So I cannot retrieve my views list after that message shows. Does any one have idea about how to resolve this problem?
Many Thanks for your kind help!
Problem solved. Delete the .ccase_wvreg_lockfile from C:\Users\username\
Note: the thread "CRMAP7007 Error reading local file area registry" gives a bit more details:
It is interesting because it reminds you of the debug options that exist with CTE:
To get a better idea of why the error is thrown you can look in the workspace log file.
This file is by default <user home>\.Rational\workspace\.metadata\.log
You can also launch CTE in debug mode by creating a .options file in the directory that he executable is in. The content of that file should be as below:
# -------------- CCRC Tracing Options File -----------------
# All line preceeded with a # sign are not evaluated.
# ------Server Tracing-------
# subsystems available:
# CCRC - Core general tracing related to CCRC server operations
# CCWEB- CCWeb(CGI operations)
# SUM - UCM specific
com.ibm.rational.clearcase/server_trace=true
com.ibm.rational.clearcase/server_trace/subsys=CCRC:CCWEB:SUM
com.ibm.rational.clearcase/server_trace/level=4
# ------Client Only Tracing-------
# Parameters available:
# HTTP_CLIENT - Tracing specific to HTTP communications
# CTRC_UI - Tracing specific to the user interface
# CTRC_CORE - For client core tracing
com.ibm.rational.clearcase/client_trace=true
com.ibm.rational.clearcase/client_trace/params=HTTP_CLIENT:4 CTRC_UI:3 CTRC_CORE:3
com.ibm.rational.clearcase/client_trace/output=file
com.ibm.rational.clearcase/client_trace/file_name=C:/temp/cte_debug.out
# -------------- END CCRC Tracing Options File -----------------
With that file created, launch CTE from the command line using the -debug option:
C:\Program Files\IBM\RationalSDLC\ClearCase\RemoteClient>ctexplorer.exe -debug
Related
After booting SWUpdate yocto-generated image for the first time, executing swupdate results in error message:
Error parsing configuration file: 'globals' section missing, exiting.
I tried to strictly follow SWUpdate's documentation, but it gets short when it comes to yocto integration. I'm using meta-swupdate, meta-swupdate-boards, and meta-openembedded layers together with poky example repository all at Kirkstone tag, building via bitbake update-image and having modyfied local.conf as:
MACHINE ??= "raspberrypi4-64"
ENABLE_UART = "1"
RPI_USE_U_BOOT = "1"
IMAGE_FSTYPES = "wic ext4.gz"
PREFERRED_PROVIDER_u-boot-fw-utils = "libubootenv"
IMAGE_INSTALL:append = " swupdate"
Is there anything else I need to modify to generate the configuration file and be able to run SWUpdate binary properly?
Side question: In the documentation, it's recommended to append swupdate-www to achieve a better web server. However, if I append it, there is no swupdate-www binary inside the `/usr/bin' directory.
As with other recipes folders the recipes-support/swupdate/swupdate/raspberrypi4-64 folder was missing inside the meta-swupdate-boards layer. Therefore, an empty config file was always generated. After adding this folder and all related files, strongly inspired by raspberrypi3 folder, the error was gone and swupdate -h provided the expected output.
There was also one new error during build process thrown by yocto. It was related to missing systemd requirement and was solved by adding:
DISTRO_FEATURES_append = " systemd"
to local.conf
I'm going to setup Oracle DB 12c on Ubuntu 16.04. I'm following this guide.
But when I was trying to STARTUP, it's fail with this error:
SQL> connect sys as sysdba
Enter password:
Connected to an idle instance.
SQL> STARTUP;
ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/u01/app/oracle/product/12.2.0/dbhome_1/dbs/initSID.ora'
SQL>
How can I resolve this?
[Update]
I have resolved this by this way:
cp init.ora ./initSID.ora
Then it STARUP as well. But I still can not access to https://127.0.0.1:5500/em
I updated env as request from #vs_coder:
LC_PAPER=vi_VN
XDG_VTNR=7
ORBIT_SOCKETDIR=/tmp/orbit-huynq
XDG_SESSION_ID=c2
LC_ADDRESS=vi_VN
CLUTTER_IM_MODULE=xim
LC_MONETARY=vi_VN
TERMINATOR_UUID=######################
IBUS_DISABLE_SNOOPER=1
XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/huynq
GIO_LAUNCHED_DESKTOP_FILE_PID=4970
SESSION=ubuntu
GPG_AGENT_INFO=/home/huynq/.gnupg/S.gpg-agent:0:1
TERM=xterm
SHELL=/bin/bash
XDG_MENU_PREFIX=gnome-
ORACLE_UNQNAME=DB12C
TMPDIR=/tmp
DERBY_HOME=/usr/lib/jvm/java-8-oracle/db
QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1
LC_NUMERIC=vi_VN
WINDOWID=75497476
OLDPWD=/u01/app/oracle/product/12.2.0/dbhome_1
GNOME_KEYRING_CONTROL=
UPSTART_SESSION=unix:abstract=/com/ubuntu/upstart-session/1000/1478
GTK_MODULES=gail:atk-bridge:unity-gtk-module
USER=oracle
http_proxy=#######################
LD_LIBRARY_PATH=/u01/app/oracle/product/12.2.0/dbhome_1/lib:/lib:/usr/lib:/usr/lib64
QT_ACCESSIBILITY=1
LC_TELEPHONE=vi_VN
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
ORACLE_SID=SID
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
UNITY_HAS_3D_SUPPORT=false
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
ORACLE_BASE=/u01/app/oracle
ORACLE_HOSTNAME=127.0.0.1
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
ftp_proxy=#######################
SESSION_MANAGER=local/huynq-VirtualBox:#/tmp/.ICE-unix/2277,unix/huynq-VirtualBox:/tmp/.ICE-unix/2277
DEFAULTS_PATH=/usr/share/gconf/ubuntu.default.path
GIO_LAUNCHED_DESKTOP_FILE=/usr/share/applications/terminator.desktop
UNITY_DEFAULT_PROFILE=unity-lowgfx
XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/usr/share/upstart/xdg:/etc/xdg
MAIL=/var/mail/oracle
PATH=/u01/app/oracle/product/12.2.0/dbhome_1/bin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
DESKTOP_SESSION=ubuntu
QT_QPA_PLATFORMTHEME=appmenu-qt5
QT_IM_MODULE=ibus
LC_IDENTIFICATION=vi_VN
JOB=unity-settings-daemon
PWD=/u01/app/oracle/product/12.2.0/dbhome_1/bin
XDG_SESSION_TYPE=x11
JAVA_HOME=/usr/bin/java
XMODIFIERS=#im=ibus
socks_proxy=#######################
SID=ORCL
LANG=en_US.UTF-8
GNOME_KEYRING_PID=
MANDATORY_PATH=/usr/share/gconf/ubuntu.mandatory.path
GDM_LANG=en_US
LC_MEASUREMENT=vi_VN
IM_CONFIG_PHASE=1
COMPIZ_CONFIG_PROFILE=ubuntu
GDMSESSION=ubuntu
https_proxy=#######################
GTK2_MODULES=overlay-scrollbar
SESSIONTYPE=gnome-session
XDG_SEAT=seat0
HOME=/home/oracle
SHLVL=2
LANGUAGE=en_US
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
LIBGL_ALWAYS_SOFTWARE=1
UPSTART_INSTANCE=
TMP=/tmp
LOGNAME=oracle
XDG_SESSION_DESKTOP=ubuntu
UPSTART_EVENTS=xsession started
COMPIZ_BIN_PATH=/usr/bin/
CLASSPATH=/u01/app/oracle/product/12.2.0/dbhome_1/jlib:/u01/app/oracle/product/12.2.0/dbhome_1/rdbms/jlib
QT4_IM_MODULE=xim
XDG_DATA_DIRS=/usr/share/ubuntu:/usr/share/gnome:/usr/local/share:/usr/share:/var/lib/snapd/desktop:/var/lib/snapd/desktop
J2SDKDIR=/usr/lib/jvm/java-8-oracle
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-5aFOIz1iEI
LESSOPEN=| /usr/bin/lesspipe %s
UPSTART_JOB=unity7
INSTANCE=
DISPLAY=:0
XDG_RUNTIME_DIR=/run/user/1000
ORACLE_HOME=/u01/app/oracle/product/12.2.0/dbhome_1
XDG_CURRENT_DESKTOP=Unity
J2REDIR=/usr/lib/jvm/java-8-oracle/jre
GTK_IM_MODULE=ibus
LC_TIME=vi_VN
LESSCLOSE=/usr/bin/lesspipe %s %s
COLORTERM=gnome-terminal
XAUTHORITY=/home/huynq/.Xauthority
LC_NAME=vi_VN
_=/usr/bin/env`
There are two types of startup parameter files for Oracle Database
pfile(also called init.ora file which's of type text ) and
spfile( which's of type binary ). Prior to version 9i, there was
only pfile, but still might be preferred but the preference is
mainly for backward compatibility with the older releases.
If startup is performed with a pfile as in your case, you need to include the file and path to file :
SQL> startup pfile=/u01/app/oracle/product/12.2.0/dbhome_1/dbs/initSID.ora
or you can create a spfile firstly by
SQL> create spfile from pfile='/u01/app/oracle/product/12.2.0/dbhome_1/dbs/initSID.ora'
and then startup
SQL> startup
without specifying any file.
For enterprise manager, you need to check
$ emctl status dbconsole and see what it tells,
and check whether ORACLE_SID parameter is set.
Looks like you need to set the environment variable ORACLE_SID to ORCL. Assuming you're in linux run this at the command line 'env', without the quotes, and update your original question with the output from that. When Oracle starts it looks for a number of environment variables, ORACLE_HOME and ORACLE_SID are 2 of the critical ones. By posting the output of the env command someone might be able to help.
Also, as a side note, I usually have better luck installing the Oracle database software first, and then creating a database using either the DBCA or the create database command. The latter is a little more advanced but is a good thing to learn.
gitolite info didn't work, adding keys turned them into a no access key and did NOT create a corresponding entry in auth-keys file.
To fix this run gitolite setup on gitolite server
Question: what could have landed me in that mess?
And what does gitolite setup do when invoked for the n-th time (it's no longer setting things up, according to the docs it fixes hooks, but I wonder what the use case would be and which was mine)?
More details on gitolite info
gitolite info command is invoked like so:
> ssh git-user#ser-git
PTY allocation request failed on channel 0
hello git-admin, this is ...#... running gitolite3 3.6.7-2 (Debian) on git 2.17.1
R W some-repository
R W gitolite-admin
R W testing
Connection to ser-git closed.
Bad output is: FATAL: unknown git/gitolite command: 'info'
More details: keys without access.
gitolite sshkeys-lint was showing keys with (no access), now those keys have access as I set them (now meaning after gitolite setup).
ssh-keygen -lf /home/repo/.ssh/authorized_keys | wc -l (or without piped part, regardless) number of keys and their names indicated I didn't have the newest one added.
Similar question that did not work for me: keydir entries not propagating to authorized_keys
Docs pretty much had the answer once I dug deeper, I guess. Which is fairly nice of #sitaramc.
Without options, 'gitolite setup' is a general "fix up everything" command
(for example, if you brought in repos from outside, or someone messed
around with the hooks, or you made an rc file change that affects access
rules, etc.)
Symptoms keys stopped propagating and error FATAL: unknown git/gitolite command: 'info' on ssh git-user#ser-git. Fix was to run gitolite setup. So onto first question, the title one:
what does gitolite setup fix?
gitolite setup is implemented here
my Perl is rather weak, but there's a setup function in line 56. It calls args (which parses options, so here it had nothing to parse), then unless h_only (hooks only arg for setup), which wasn't used, so we skip compile and POST_COMPILE trigger and go for the hooks.
sub setup {
my ( $admin, $pubkey, $h_only, $message ) = args();
unless ($h_only) {
setup_glrc();
setup_gladmin( $admin, $pubkey, $message );
_system("gitolite compile");
_system("gitolite trigger POST_COMPILE");
}
hook_repos(); # all of them, just to be sure
}
package Gitolite::conf::store has hook_repos(), line 228: we change the dir to repo base dir (as per config file), and for each phy_repo we do hook_1(phy_repo). What is a phy_repo? a physical one.
same package, different method and line: hook_1($repo) in line 354.
Method hook_1($repo)
It's quite literally about fixing all the hooks.
Recreates dirs for common and admin hooks.
Rewrites update_hook (common) and post_update_hook (admin).
Sets 755 permissions for both common and admin hooks.
Then using ln_sf it symlinks the folders for common/admin hooks.
ln_sf is in common module, in line 162
I added iptables package to my device image, using CORE_IMAGE_EXTRA_INSTALL += "iptables".
I tried to run it on the device and get the following error message:
modprobe: FATAL: Module ip_tables not found in directory /lib/modules/4.9.11-1.0.0+gc27010d
iptables v1.6.1: can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
Seems like I have missing kernel module.
Need your help in adding standard kernel module to the image (Where can I find all modules files and how should I add and load it to the image).
You must add the iptables module to your kernel. I had the same problem and I could solve it with these steps:
Run bitbake -c menuconfig virtual/kernel
Activate CONFIG_IP_NF_IPTABLES module (you can search its location on that menu typing slash '/').
Save it and run bitbake -c savedefconfig virtual/kernel for saving that file as a defconfig.
Copy defconfig file from returned path to yocto-distro/layer-name/recipes-kernel/linux/files/ (make this directory if it does not exist).
Create a .bbappend file inside yocto-distro/layer-name/recipes-kernel/linux/ with the same name as your original recipe file from meta layer.
Edit your file and append lines below:
SRC_URI += "file://defconfig"
KERNEL_DEFCONFIG = "${WORKDIR}/defconfig"
FILESEXTRAPATHS_prepend := "${THISDIR}/files"
~
Relaunch bitbake your-image-name
It worked on my situation. Btw, I got that info from the following webs:
http://variwiki.com/index.php?title=Yocto_Customizing_the_Linux_kernel
https://www.linuxtopia.org/Linux_Firewall_iptables/x651.html
Have a nice day! :D
Summary: Unable to run any of the most simple “Hello World” FastCGI script, any request always terminating into a time out. Seems there is no communication at all between the server and the FastCGI scripts (using dynamic FastCGI scripts).
The environment
Ubuntu Precise (12.04)
Package apache2.2-bin
Package apache2-mpm-prefork
Package libapache2-mod-fastcgi
Package libfcgi-perl
Package python-flup
Multiple sites configured as virtual hosts on 127.0.0.1
There exists a /var/lib/apache2/fastcgi directory, owned by www-data, readable by all (owner, group and others)
There exists a /var/lib/apache2/fastcgi/dynamic directory, owned by www-data, which is restricted to the owner (readable, writable and accessible by www-data only)
There exists an inode/socket file in the /var/lib/apache2/fastcgi/ directory
The FastCGI relevant configurations:
The directory /etc/apache2/mods-enabled/ holds a reference to fastcgi.conf and fastcgi.load (mod_fastcgi is enabled).
The file fastcgi.conf contains the following (left untouched, I did not edit it):
<IfModule mod_fastcgi.c>
AddHandler fastcgi-script .fcgi
#FastCgiWrapper /usr/lib/apache2/suexec
FastCgiIpcDir /var/lib/apache2/fastcgi
</IfModule>
The relevant configuration file in /etc/apache2/sites-enabled/ contains the following (there is nothing more anywhere else about FastCGI specific configuration):
<DirectoryMatch /fcgi-bin>
Options +ExecCGI
<FilesMatch "^[^\.]+$">
SetHandler fastcgi-script
</FilesMatch>
</DirectoryMatch>
The test materials on the test virtual host:
There exist a fcgi-bin/test-perl.fcgi whose content is (the file is executable by all, and readable by owner and group):
#!/usr/bin/perl
use CGI::Fast qw(:standard);
$COUNTER = 0;
while (new CGI::Fast) {
print header;
print start_html("Fast CGI Rocks");
print
h1("Fast CGI Rocks"),
"Invocation number ",b($COUNTER++),
" PID ",b($$),".",
hr;
print end_html;
}
There exist a fcgi-bin/test-python.fcgi whose content is (the file is executable by all, and readable by owner and group):
#!/usr/bin/python
def myapp(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/plain')])
return ['Hello World!\n']
try:
from flup.server.fcgi import WSGIServer
WSGIServer(myapp).run()
except:
import sys, traceback
traceback.print_exc(file=open("errlog.txt","a"))
The issue
Although both fcgi-bin/test-perl.fcgi and fcgi-bin/test-python.fcgi runs normally when executed from the command‑line, none seems to work when invoked, e.g. as http://test.loc/fcgi-bin/test-perl.fcgi or http://test.loc/fcgi-bin/test-python.fcgi.
Nothing at all happens, and after some delay, I get an Error 500, and Apache error logs contains multiple entries looking like:
[<date>] [error] [client <IP>] FastCGI: comm with (dynamic) server "/<…>/fcgi-bin/<script>.fcgi" aborted: (first read) idle timeout (30 sec), referer: <referrer>
[<date>] [error] [client <IP>] FastCGI: incomplete headers (0 bytes) received from server "<…>/fcgi-bin/<script>.fcgi", referer: <referrer>
I've spent hours and hours searching the web trying to understand why it does not work, and finally decided to give up and ask for some help here.
Any pointers and check list welcome. Feel free to ask for any missing details you may feel to be relevant or worth checking.
Enjoy a nice day.
-- edit --
Issue update
In my own reply to my own question, I mentioned a weird case where things were looking suddenly fine without reasons. I later discovered this was only partly fine.
In the same virtual host, so with the exact same server configuration, some scripts, which are exactly the same (and with exact same access rights), fails depending on their location.
As a remainder, here is what's in the site configuration:
<DirectoryMatch /fcgi-bin>
Options +ExecCGI
<FilesMatch "^[^\.]+$">
SetHandler fastcgi-script
</FilesMatch>
</DirectoryMatch>
With the above, only scripts in /fcgi-bin are handled as FastCGI script. But I also have some elsewhere (still for testing): one in /cgi-bin and one in / (i.e. in the public_html directory). For this purpose, .htaccess contains this entry:
Options +ExecCGI
AddHandler fastcgi-script .fcgi
So the two others FastCGI script should work the same as the one in /fcgi-bin, but they don't, and for the time, they invariably terminates with a connexion time‑out, just like the one /fcgi-bin first did.
This makes me feel something may be wrong with the mod_fastcgi module (known bug? else?). So far, this module seems to act rather randomly.
-- edit 2 --
The above in the first edit, was an error of mine: the group was wrong with the other scripts, it had to be www-data, but it was not. So is something is wrong, stick to the answer I gave, that is, try to look at the FastCgiConfig, and see if it solve anything or at least if it honours the time‑out options.
I will answer my own question, as it seems to be working now. However, the epilogue still looks weird.
Although the default configuration should be OK, I still wanted to review the “Module mod_fastcgi” document again. As I only wanted a dynamic FastCGI, I focused on the FastCgiConfig directive only, thus on purpose not going into FastCgiServer and FastCgiExternalServer directives.
As there was no FastCgiServer at all in the default fastcgi.conf file, I started to try to set‑up my own. For a first test, I wanted to use the -appConnTimeout option, at least to request the server to not wait so much long before it returns me an Error 500.
So I just added this in the site configuration (I did not touch fastcgi.cong), in the same file where virtual hosts are configured:
FastCgiConfig -appConnTimeout 2
This was to tell the server to wait no more than 2 seconds, instead of the 30 seconds it was waiting. I tried to invoked a FastCGI script to see if at least this configuration was working. I expected to get an error in a 2 seconds delay, but instead, the script ran without error.
What's weird, is that I then tried to remove this option, to check if it was just that addition which was just missing to make FastCGI scripts working. But after I commented‑out the option, it was still working, and the same after a full reboot.
Can't tell more, that looks weird, but this is the only thing I did, I did not edit anything else. I can just suggest people who may encounter a similar issue, to just try the above.
Sorry, if I can't explain what it did exactly. I really would like to know. It just working now, but I don't know why.
#############
fastcgi.conf
FastCgiWrapper Off
peng.rl 's answer solve my problem.
My ceph radosgw can't get apache's input at all. after set FastCgiWrapper Off, I can capture data in wireshark.