Sunday 6 December 2020

How To Make A Field Editable On JIRA Issue Screen?

At times you get request from your team to make the field editable on Jira Issue Screen. Please follow below simple steps in order to get that done -

  • Go to 'Settings' and then 'Issues' under that
  • Click on 'Screens'
  • Look for the screen which you want to modify
  • You'll see three different screens for each issue type
    1. ITS Screen
    2. ITS Screen - Edit
    3. ITS Screen - View
  • Select 'XXX ITS Screen - Edit' 



  • Now, you can configure screen.
  • Please add the field which you want to make editable for that particular screen.
That's it! Thanks for reading.

Saturday 6 June 2020

How To Set-Up SSH Account On AWS Instance

How To Set-Up SSH Account On AWS Instance

1. Login to the server using root account. If you aren't logged in as root then you will have to use sudo before all scripts explicitly.
2. Create a user for whom you want to set-up SSH account.
    adduser <new_user>

If above command not working then try with force command as below -

    adduser --disabled-password --force-badname "sumit.pandey"

3. Now, user is added the machine. Switch user to new one.
    sudo su - <new_user>

If above command doesn't work then simply go to newly created users directory using cd 

    cd /home/<new_user>

4. Create .ssh directory in new user's home directory.
    mkdir .ssh

5. Change .ssh directory's permission to 700. Changing the permission restricts access so that only the <new_user> can read, write, or open the .ssh directory.
    chmod 700 .ssh

6. Create authorized_keys file under .ssh directory.
    touch .ssh/authorized_keys

7. Change the authorized_keys file permission to 600. It restricts file access to <new_user> only.
    chmod 600 .ssh/authorized_keys

8. Open authorized_keys in edit mode and put the public key of the <new_user> in it.
    cd .ssh/
    vi authorized_keys

9. Save and quit.

10. It's done. Go back and try connecting from your machine using the private key file.

11. Hurray!! it's working.

12. If not working then execute below two commands after going to newly created user's directory -

     cd /home/<new_user>

     chown sumit.pandey:sumit.pandey .ssh

      chown sumit.pandey:sumit.pandey .ssh/authorized_keys

Example - I tried to set-up SSH account for user pandey on my bastion host and then tried connecting it from my windows machine -

(a) Setting of account on Bastion server.

[root@ip-172-31-38-17 sumit]# adduser pandey
[root@ip-172-31-38-17 sumit]# sudo su - pandey
[pandey@ip-172-31-38-17 ~]$ mkdir .ssh
[pandey@ip-172-31-38-17 ~]$ chmod 700 .ssh/
[pandey@ip-172-31-38-17 ~]$ chmod 700 .ssh
[pandey@ip-172-31-38-17 ~]$ touch .ssh/authorized_keys
[pandey@ip-172-31-38-17 ~]$ chmod 600 .ssh/authorized_keys 
[pandey@ip-172-31-38-17 ~]$ cd .ssh/
[pandey@ip-172-31-38-17 .ssh]$ vi authorized_keys 


(b) Connected from the windows machine using putty. Don't forget to use .ppk file under Auth while accessing bastion host using putty.



Important Points::


1. If the end user is linux user then you can ask him to generate his /her private and public keys using ssh-keygen command on his machine. Take his public key (id_rsa.pub) and put in authorized_key file under his account on your bastion host.

2. If the end-user is windows user then ask him to generate the RSA keys using puttygen. The public key generated by puttygen won't be in ready format to provide access, hence, make sure to add it one line by prefixing ssh-rsa like below -

ssh-rsa AAAAB3XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX==

Friday 5 June 2020

How To Edit Customised Field In JIRA Project OR Add A New Custom Field



1. Select the project in JIRA for which you want to customise the field selection.

2. Click on 'Issue Types' and pick relevant Screen.

3. Click on 'Custom Fields' under fields.

4.

  • Now, if you want to add a new filed then choose 'Create custom field' and proceed further.
  • If you want to edit already exiting field then open that field and go to 'Contexts'
5. Go to 'Create, edit or delete' contexts.
6.  Select 'Edit Options' and make required changes.
7. You're done!

Thursday 21 May 2020

Grafana Installation Using Repo File On AWS Instance

Hello Guys, Hope everyone doing good and staying safe.

Let me explain the process of installing Grafana - a widely used tool for monitoring pre defined AWS Systems metrics and custom metrics too. The process is very straight forward and simple.

Prerequisites: Provision an instance on AWS using your key file and SSH on it.

Step 1: Change to Root user - sudo su

Step 2: The installation is via yum repository. Create a grafana.repo under /etc/yum.repos.d/ 

vi grafane.repo

Step 3: Put below content in grafana.repo and save it.

[grafana]
name=grafana
baseurl=https://packages.grafana.com/oss/rpm
repo_gpgcheck=1
enabled=1
gpgcheck=1
gpgkey=https://packages.grafana.com/gpg.key
sslverify=1

sslcacert=/etc/pki/tls/certs/ca-bundle.crt


Step 4: Once done with above steps. It's time to install grafana now.

sudo yum -y install grafana

Step 5: That's it. You have done a great job. The installation is done. Restart the service.

service grafana-server start

Sunday 5 January 2020

Moving Index from One Splunk Indexer To Another





Moving indexes in Splunk can be required in migrations, upgrades or simply as an exercise for backup and restores.
In this example, we will move an index called SSG from a Splunk 7.02 server called UBUNTU07 running on Ubuntu Linux to another 7.02 Splunk server running on another Ubuntu server called SPLUNKOSAUR. We are assuming that Splunk is installed in the default Linux location (/opt/splunk) and that the indexes are in the default Splunk location (/opt/splunk/var/lib/splunk) – if not, adjust the paths accordingly. For Linux/Windows combinations, the copy commands have to be adjusted accordingly but otherwise the overall process remains the same.
Step 1
On the new server, create an index with the same name. In this case we will create an index called SSG on SPLUNKOSAUR:
Create new index
Step 2
Stop Splunk on the new server (SPLUNKOSAUR). From a terminal  run:
sudo /opt/splunk/bin/splunk stop
Step 3
Remove the folder for the newly created index:
sudo rm -r /opt/splunk/var/lib/splunk/ssg
Remove new index
Step 4
On the old server, remove or disable any inputs that send data to the index that has to be migrated. In our case, we have a file monitor input that ingests a Juniper SSG firewall syslog logs into the SSG index:
Disable input
Step 5
Stop Splunk on the old server (UBUNTU07):
sudo /opt/splunk/bin/splunk stop
Step 6
Transfer the folder containing the index to be migrated to the new server. There are several ways to transfer folders between servers. In our case, we will use the scp utility (secure copy) that ships with any Ubuntu installation. scp is using SSH so the servers have to run the SSH daemon. If SSH is not installed, the installation is rather simple. In a terminal prompt run:
sudo apt-get install openssh-server
To check the status of the SSH server run:
sudo service ssh status
Once SSH is installed on the receiving server, you can use the scp utility. To transfer a full folder use the following command:
sudo scp -r /opt/splunk/var/lib/splunk/ssg user_name@server_name_or_ip:”/opt/splunk/var/lib/splunk/ssg”
Replace user_name and server_name_or_ip with the corresponding values. In our case, SPLUNKOSAUR has an IP address of 192.168.5.25 and we will use a user called jdoe so the syntax would be:
sudo scp -r /opt/splunk/var/lib/splunk/ssg jdoe@192.168.5.25:”/tmp”
scp command
This will transfer the ssg folder to the /tmp folder on the new server.
The user will be prompted for the password and if entered correctly, the copying will be initiated. The duration of the copying process will depend on the amount of data to be transferred and the type of connectivity between servers. If the volume of data is very large and/or the connectivity between servers is slow or inexistent, then the files can be transferred with a portable media such as an USB drive. In any case, the end results have to be the same: the existing SSG index folder from the old server has to end up in the indexes folder on the new server.
scp completed
Step 7
On the new server, transfer the ssg folder from /tmp to /opt/splunk/var/lib/splunk. Depending on the user that you are logged in as, you may have to become root (i.e. use the “sudo -i” command to facilitate all the rest of the commands that you need to configure the new folder properly):
mv ssg /opt/splunk/var/lib/splunk
After the transfer, the /opt/splunk/var/lib/splunk folder on the new server should look something like this:
new server listing
Step 8
Note that the ssg folder has as owner and group the user that was used to transfer the folder (jdoe). Adjust the ownership of the SSG folder to match the existing indexes:
chown root:root /opt/splunk/var/lib/splunk/ssg
The folder should indicate root as owner and group:
change folder owner
Step 9
Start Splunk on the new server (SPLUNKOSAUR):
/opt/splunk/bin/splunk start
Login into the new server and verify that the SSG index has all the data from the old server:
New index migrated
Perform a search to validate that the data is available:
data present
Recreate the inputs as needed. This depends on the nature of the previous inputs, i.e. if the input was for local files, the source of the data will have to be transferred to the new server or the old server configured as a forwarder.
Step 10
As the last step, restart the old server and remove the old index.
NOTE: The information here is copied from below link -