Secure Url redirection-https- WildFly-8.2.0

Generate a keystore and self-signed certificate:

Sample certificate created with the following information.

 

$>keytool -genkey -alias mycert -keyalg RSA -sigalg MD5withRSA -keystore my.jks -storepass secret  -keypass secret -validity 9999

 

What is your first and last name?

  [Unknown]:  localhost

What is the name of your organizational unit?

  [Unknown]:  TallJavaThoughts

What is the name of your organization?

  [Unknown]:  TallJavaThoughts.com

What is the name of your City or Locality?

  [Unknown]:  Blr

What is the name of your State or Province?

  [Unknown]:  Kr

What is the two-letter country code for this unit?

  [Unknown]:  IN

Is CN=localhost, OU=TallJavaThoughts, O=TallJavaThoughts.com, L=Blr, ST=Kr, C=In correct?

  [no]:  yes

 

You will get the my.jks created in the current path and the same needs to be placed in wildfly-8.2.0.Final\standalone\configuration.

 

Need to add a new security realm in standalone.xml file as follows:

<security-realm name="UndertowRealm">

                <server-identities>

                    <ssl>

                        <keystore path="my.jks" relative-to="jboss.server.config.dir" keystore-password="secret" alias="mycert" key-password="secret"/>

                    </ssl>

                </server-identities>

            </security-realm>

 

Undertow Subsystem for SSL needs to be configured:

<https-listener name="https" socket-binding="https" security-realm="UndertowRealm"/>

That's it!

ORA-01157 and ORA-01110 while trying to bring the tablespace online

ORA-01157 and ORA-01110 while trying to bring the tablespace online




Issue:


SQL> alter tablespace example online;
alter tablespace example online
*
ERROR at line 1:
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: 'C:\ORACLE\.........\ORADATA\ORCL\EXAMPLE01.DBF'


Cause:


The background process was either unable to find one of the data files or failed to lock it because the file was already in use.


The database will prohibit access to this file but other files will be unaffected. However the first instance to open the database will need to access all online data files. Accompanying error from the operating system describes why the file could not be identified.


Have operating system make file available to database. Then either open the database or do ALTER SYSTEM CHECK DATAFILES.


ORA-01157 is caused by a locking issue with the database writer (DBWR) background process.  During a recovery, this can be caused by a unopened data files (i.e. database mounted but not open), a missing file, a permission problem in the file (e.g. no write permissions 770 on the files owned by Oracle).


If the background process is unable to reach a data file, or is unable to lock it because it is in use , ORA-01157 is thrown because the database does not allow access. The other files will not be affected, but it is important to know that opening the database using the first instance will need to use online data files. there should be other errors which appear along with ORA-01157 to aid in resolving the problem.


Straightening out ORA-01157 consists of making the files of the database available, and either regularly opening the database, or use ALTER SYSTEM CHECK DATAFILES.




Solution:
Change the access permissions to file. Example, chmod 777 file_name.

Kill multiple sessions at a time in Oracle

Here the story begins, I tried dropping a user and end up with the below error:

ERROR at line 1:
ORA-01940: cannot drop a user that is currently connected

I checked the associated sessions,

select sid, serial# from v$session where username ='DBUSER';

If this returns a single row, you can simply kill the session using the below command

alter system kill session 'sid,serial#';

what if I have multiple rows?The below procedure will help you to do this:

create or replace
PROCEDURE "KILL_ALL_SESSION" AS
BEGIN
declare
str varchar2(100);
lockUser varchar2(100);
unLockUser varchar2(100);
BEGIN
lockUser := 'alter user DBUSER account lock';
unLockUser:= 'alter user DBUSER account unlock';
execute immediate lockUser;
dbms_output.put_line(lockUser);
begin
for S in (select sid,serial# from v$session where username ='DBUSER'
and username != 'SYS')
loop
str := 'alter system kill session '||chr(39)||S.sid||','||S.serial#||chr(39);
dbms_output.put_line(S.sid);
execute immediate str;
end loop;
end;
END ;
END KILL_ALL_SESSION;

Okay, what is the use of lockUser/unLockUser here? Well, this is needed, to drop users who automatically establish session. So that time we may need to lock the account for further connection attempts.

We can lock/unlock the users using the following commands:

alter user DBUSER account lock;
alter user DBUSER account unlock;