<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Forem: feng wei</title>
    <description>The latest articles on Forem by feng wei (@feng_wei).</description>
    <link>https://forem.com/feng_wei</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1531916%2Fab7975e2-73d0-4081-9602-fc69f84f6a4b.png</url>
      <title>Forem: feng wei</title>
      <link>https://forem.com/feng_wei</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://forem.com/feed/feng_wei"/>
    <language>en</language>
    <item>
      <title>Ubuntu 22.04: Browser Not Working After Hardening</title>
      <dc:creator>feng wei</dc:creator>
      <pubDate>Thu, 05 Sep 2024 02:23:36 +0000</pubDate>
      <link>https://forem.com/feng_wei/ubuntu-2204-browser-not-working-after-hardening-37gc</link>
      <guid>https://forem.com/feng_wei/ubuntu-2204-browser-not-working-after-hardening-37gc</guid>
      <description>&lt;p&gt;I notice that web browsers, like Firefox and Chrome, will cease functioning after applying Ubuntu security guide - level1_workstation in some Ubuntu 22.04.&lt;/p&gt;

&lt;p&gt;Error is like as following:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;&lt;em&gt;snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks. Please make sure that the snapd.apparmor service is enabled and started.&lt;/em&gt;&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;I am pretty sure that "snapd.apparmor service is enabled and started" after a quick check. With some Google research, i believe the issue is caused by a Linux Security Module called AppArmor, which restricts applications' capabilities and permissions with profiles that are set per-program. You can find more info about it &lt;a href="https://ubuntu.com/server/docs/apparmor" rel="noopener noreferrer"&gt;here&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;In short, AppArmor profiles have two modes of operation:&lt;/p&gt;

&lt;p&gt;Complaining/Learning: profile violations are permitted and logged. This is useful for testing and developing new profiles.&lt;/p&gt;

&lt;p&gt;Enforced/Confined: enforces profile policy in addition to logging the violation.&lt;/p&gt;

&lt;p&gt;To solve the issue, we can set all profiles modes to "Enforced".&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;sudo aa-enforce /etc/apparmor.d/*
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;To verify profiles status, fire command "sudo aa-status"&lt;/p&gt;

</description>
      <category>ubuntu</category>
    </item>
    <item>
      <title>visudo and /etc/sudoers</title>
      <dc:creator>feng wei</dc:creator>
      <pubDate>Thu, 15 Aug 2024 02:49:09 +0000</pubDate>
      <link>https://forem.com/feng_wei/visudo-and-etcsudoers-3jef</link>
      <guid>https://forem.com/feng_wei/visudo-and-etcsudoers-3jef</guid>
      <description>&lt;p&gt;It may not be a good idea to grant full root-equivalent privilege to Unix-like OS users. Access should be granted based on actual needs. &lt;/p&gt;

&lt;p&gt;You should not edit sudoers directly, by opening it in a text editor. Instead, edit it with visudo, which will verify its validity before saving the changes to disk.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;/etc/sudoers&lt;/strong&gt;&lt;/p&gt;




&lt;h1&gt;
  
  
  Host alias specification
&lt;/h1&gt;

&lt;h1&gt;
  
  
  User alias specification
&lt;/h1&gt;

&lt;h1&gt;
  
  
  Cmnd alias specification
&lt;/h1&gt;

&lt;h1&gt;
  
  
  User privilege specification
&lt;/h1&gt;

&lt;p&gt;root  ALL=(ALL:ALL) ALL&lt;/p&gt;

&lt;h1&gt;
  
  
  Members of the admin group may gain root privileges
&lt;/h1&gt;

&lt;p&gt;%admin ALL=(ALL) ALL&lt;/p&gt;

&lt;h1&gt;
  
  
  Allow members of group sudo to execute any command
&lt;/h1&gt;

&lt;p&gt;%sudo ALL=(ALL:ALL) ALL&lt;/p&gt;




&lt;p&gt;Here, "root ALL=(ALL:ALL) ALL" states that the user root, logged in to any hostname, may run, as a user or group, any command. The general form of this directive is:&lt;/p&gt;

&lt;p&gt;&lt;em&gt;&lt;strong&gt;user hostname=(run-as-user:run-as-group) command&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;The special word ALL may be used for any of these values and means that any are allowed.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;&lt;em&gt;hope myhost=(mysqluser:mysqlusers) mysqldump&lt;/em&gt;&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;User hope, when logged in to host myhost, may run the command mysqldump as user mysqluser or a member of group mysqlusers. For example, this directive would allow user hope to run this command:&lt;/p&gt;

&lt;p&gt;sudo -u mysqluser -g mysqlusers mysqldump&lt;/p&gt;

</description>
      <category>linux</category>
    </item>
    <item>
      <title>Case Sharing: temporary failure in name resolution</title>
      <dc:creator>feng wei</dc:creator>
      <pubDate>Thu, 20 Jun 2024 09:44:48 +0000</pubDate>
      <link>https://forem.com/feng_wei/case-sharing-temporary-failure-in-name-resolution-12b9</link>
      <guid>https://forem.com/feng_wei/case-sharing-temporary-failure-in-name-resolution-12b9</guid>
      <description>&lt;p&gt;A Linux user reported that his Ubuntu 20.04 machine could not be accessed via SSH after a reboot.&lt;/p&gt;

&lt;p&gt;Initially, I suspected a hardware issue or boot error, so I checked the machine physically from the console. However, the system was fully operational and ready for console login. I then suspected an Internet connection issue. Strangely, I could SSH into the machine from another device on the same network segment as the Ubuntu machine.&lt;/p&gt;

&lt;p&gt;The Ubuntu machine has two network connections: one for Internet access (DHCP) and another for direct connection to a storage server (static IP).&lt;/p&gt;

&lt;p&gt;I ran the command "ping google.com" and received the error "temporary failure in name resolution." This indicated a DNS issue. Normally, DNS configuration should be managed by DHCP. I used the "sudo nmtui" command to check the properties of the two connections and discovered that the "Gateway" was incorrectly configured for the direct connection. The issue was resolved after I removed the incorrectly configured gateway and restarted the connection.&lt;/p&gt;

&lt;p&gt;Summary:&lt;br&gt;
The root cause was an incorrectly configured gateway for the direct connection, despite having an Internet connection via DHCP. The direct connection became the default route, causing the name resolution failure.&lt;/p&gt;

&lt;p&gt;Commands used in troubleshooting:&lt;br&gt;
1.ping #test Internet connection.&lt;br&gt;
2.nmtui #network manager GUI&lt;br&gt;
3.cat /etc/resolv.conf #check DNS server&lt;br&gt;
4.systemctl status systemd-resolvd.service #check DNS resolver service status&lt;br&gt;
5.systemd-resolve --status #DNS summary&lt;/p&gt;

</description>
    </item>
    <item>
      <title>First Glance at Ansible</title>
      <dc:creator>feng wei</dc:creator>
      <pubDate>Fri, 31 May 2024 02:03:37 +0000</pubDate>
      <link>https://forem.com/feng_wei/first-glance-at-ansible-3522</link>
      <guid>https://forem.com/feng_wei/first-glance-at-ansible-3522</guid>
      <description>&lt;p&gt;What is ansible&lt;/p&gt;

&lt;p&gt;Ansible is an open-source IT automation tool that automates provisioning, configuration management, application deployment, orchestration, and many other IT processes. Ansible is written in Python and uses OpenSSH for transport.&lt;/p&gt;

&lt;p&gt;Hands-on Ansible&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Install ansible on a Linux machine, which is called control node. Use "ssh-keygen" and "ssh-copy-id"commands to generate ssh key and copy it to managed nodes for authentication&lt;/li&gt;
&lt;li&gt;Playbooks are the simplest way in Ansible to automate repeating tasks in the form of reusable and consistent configuration files. Playbooks are scripts defined in YAML files and contain any ordered set of steps to be executed on managed nodes.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;[My first playbook]&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;- hosts: webserver
  remote_user: whocare

  tasks:
  - name: make ~/whocare directory
    ansible.builtin.file:
      path: ~/whocare
      state: directory

  - name: Copy file 
    copy:
     src: /home/whocare.deb
     dest: /home/whocare.deb
     owner: whocare
     group: whocare
     mode: '0700'

  - name: install whocare
    become: true
    become_method: sudo
    ansible.builtin.apt:
      deb: /home/whocare.deb

  - name: copy dat file to /opt/Tanium/TaniumClient
    become: true
    become_method: sudo # need "-K" parameter, which is short form "--ask-become-pass". $ ansible-playbook &amp;lt;1.yaml&amp;gt; -K. 
    copy:
      src: /home/whocare.dat
      dest: /opt/whocare.dat

  - name: restart service
      become: true
      become_method: sudo
      service:
        name: whocare
        state: restarted
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;3.Ansible configuration file. Default location is /etc/ansible/ansible.cfg. However, you can customize your owner configuration file and put it in your ansible playbook folder to "overwrite" default config. My ansible config file, for example:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;[defaults]
inventory = ~/ansible_code/inventory/inventory.ini
private_key_file = ~/.ssh/ansible #private key!!! I put public key wrong and took me sometime for troubleshooting SSH key login issue.
log_path = ~/ansible_code/ansible.log #Log file to save all output for recording and troubleshooting
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



</description>
      <category>ansible</category>
    </item>
    <item>
      <title>Synology-Shared Folder Access Error</title>
      <dc:creator>feng wei</dc:creator>
      <pubDate>Tue, 28 May 2024 06:02:24 +0000</pubDate>
      <link>https://forem.com/feng_wei/synology-shared-folder-access-error-g23</link>
      <guid>https://forem.com/feng_wei/synology-shared-folder-access-error-g23</guid>
      <description>&lt;p&gt;Background:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;A Synology NAS is connected two networks, N1 and N2, both are able to reach Domain X.&lt;/li&gt;
&lt;li&gt;The NAS was joined Domain X via N1. Share folders access is configured for domain users.&lt;/li&gt;
&lt;li&gt;The NAS was disconnected from N1 recently.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Issue:&lt;br&gt;
Users reported shared folder is inaccessible due to "Network Error".&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fctwf95zquo9fy13mtuz4.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fctwf95zquo9fy13mtuz4.png" alt="Image description" width="529" height="243"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Actions(Done within N2):&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Verify NAS OS status and test shared folder access. OS is normal but shared folder can't be accessed.&lt;/li&gt;
&lt;li&gt;Restart SMB service then following by restarting NAS. Issue persists. &lt;/li&gt;
&lt;li&gt;Check default gateway and domain status. Noticed that domain was unavailable. Issue is rectified after rejoining Domain X with N2.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Conclusion:&lt;br&gt;
Domain availability will cause shared folder access issue due to authentication, possibly.  &lt;/p&gt;

&lt;p&gt;I also noticed the same error, which appears to be caused by a time synchronization issue. In this case, the NAS NTP server was invalid, leading to a time discrepancy of more than 5 minutes between the domain and the NAS itself.&lt;/p&gt;

</description>
      <category>synology</category>
    </item>
  </channel>
</rss>
