Skip to main content

the avatar of Robbi Nespu

How to disable ICMP ping replies (linux)

Few weeks ago during server setup phase for one of my project, I notice there is no ICMP or ping replies from server and some port are not able to access.

I told the network engineer to check and seem they blocking the ports and disabling ICMP replies from their firewall configuration.

From that accident I do some google-fu if I can do same thing for personal computer / server. We can setting the kernel variable or use iptable to disable ICMP / ping replies if requested.

Temporarily disable ICMP / ping replies

$ su -
echo "1" >  /proc/sys/net/ipv4/icmp_echo_ignore_all
# This instructs the kernel to simply ignore all ping requests
# 1 = ignore ping requests and 0 = allow ping request

or

$ iptables -A INPUT -p icmp -j DROP

Permanently disable ICMP / ping replies

To disable ping requests permanently, add this line into your /etc/sysctl.conf file:

net.ipv4.icmp_echo_ignore_all = 1

And reload sysctl’s policy by # sysctl -p.

Or save iptables rule by

# for distros with systemd
/usr/libexec/iptables.init save

# for all other distros
service iptables save

# univeral way: edit main config by yourself
vim /etc/sysconfig/iptables
the avatar of openSUSE News

Advancing openSUSE Images for The PinePhone

Awareness grew after a post in an online forum appeared in June about openSUSE images for the PinePhone, which is a smartphone developed by Pine64 that allows user to have full control over their device and run mainline Linux.

“I am working on porting openSUSE for PinePhone,” the post began. “I am working on some improvements porting all packages to openSUSE. I am working with Open Build Service, so soon we will have news about it.”

Replies to the post began to fill the page and word spread. At the moment the animation of the logo became visible on the PinePhone screen, pictures were taken, posted to social media and comments began to spread on Twitter.

“The most interesting thing about my work with the PinePhone was creating the Geeko logo boot animation,” said Adrian Campos Garrido, who took the hobby project to an official capacity.

Garrido, who is a Platform Architect, did this by bringing his passion and work to the devel project, submitted the packages he was using for the project to openSUSE Factory and began building the official images in OBS.

“I am very happy with all the migration to OBS since it allows me to do the work I did before but everything is much more efficient and more comfortable,” he said. “My interest in the PinePhone came from the first moment because it was a device with great possibilities of becoming the first device at a reasonable price that works practically the same as a computer; since it was presented as integrated into the mainline kernel of GNU/Linux.”

The first steps focused on how to create an operating system image, Garrido said, who is interested in everything related to technology and open source.

“For this I used a series of scripts and a Jenkins slave on my servers to create an image,” he said. “Then, I started to port all the packages to openSUSE; starting by learning how the Spec Files worked for building RPM packages.”

His journey of building the openSUSE images for the PinePhone wasn’t easy.

“The most difficult thing was to adapt the kernel with the package to make the calls and the audio work.”

There are still some known issues that need fixing like the Bluetooth, accelerometer and GPS. Garrido has been focused on keeping the releases as stable as possible and plans on progressing with a roadmap to allow him to have a clearer objective of where to continue.

“Any help is welcome from helping with the maintenance of the package to reporting bugs,” he said. “Reporting is very interesting and allows me to prioritize some tasks over others.”

People can contact Garrido on GitHub and find out how to help on the openSUSE images wiki page.

a silhouette of a person's head and shoulders, used as a default avatar

openSUSE Tumbleweed – Review of the week 2020/49

Dear Tumbleweed users and hackers,

Week 49 felt like a normal week, with no disasters happening, steady rolling distribution, openQA being on our side, blocking one snapshot that could have caused quite some pain to you, the users. So all in all, exactly what we want from a stable, rolling distribution. And this still resulted in 5 snapshots released during this week (1127, 1129, 1130, 1201, 1202).

The main changes in those five snapshots included:

  • Mozilla Firefox 83.0
  • Grep 3.6: the GREP_OPTIONS environment variable no longer affects grep’s behavior
  • GNOME 3.38.2
  • Linux kernel 5.9.11

In the staging projects, these changes are being tested and worked on:

  • KDE Plasma 5.20.4
  • KDE Applications 20.12 (currently RC being tested)
  • icu 68.1: breaks a couple of builds (Staging:I)
  • brp-check-suse: a bug fix in how it detected dangling symlinks (it detected them, but did not fail as it was supposed to)
  • permissions package: prepares for easier listing, while supporting a full /usr merge
  • RPM 4.16: still a few packages build failures (postgresql, Mozilla *, openblas)
  • Ruby 3.0: mainly YaST not ready for that switch
  • First experiments with rpmlint 2.0 started in Staging:M
  • openssl 3.0: currently alpha 9 in Staging:O
the avatar of YaST Team

Digest of YaST Development Sprint 114

Fortunately, Christmas is around the corner and the year 2020 is coming to an end. But the YaST team is not thinking about going on holidays yet. Quite the contrary, we have been working on a broad range of topics as usual. So let’s have a look at some of them.

Polishing the Cockpit Wicked Module

At the end of the sprint, we released a new version of our Cockpit Wicked module. This release does not include big changes but a set of bug fixes and small improvements. Actually, at this point, we have decided to shift our focus from adding features to polishing the module as much as possible.

Interfaces List

As part of this new focus, we have asked our usability experts how to build a better user experience. Additionally, we have started the process to make the module available for translation in our Weblate instance to get it properly localized.

On the other hand, the initial research for the Cockpit Transactional Update module is over. We are now working on documenting our requirements to resume the development work soon.

Better Support for tmpfs in the Partitioner

While introducing the new storage stack in SLE 15, we decided to drop support for creating tmpfs entries in the /etc/fstab using AutoYaST. After all, systemd is already taking care of handling such file systems. However, our users want this behavior back and we are now introducing proper handling in YaST for tmpfs file systems.

As a first step, we added support in the partitioner to manage those entries. Please, beware that YaST will only take care the devices listed in /etc/fstab. Any tmpfs file system created by systemd or any other mechanism is out of our scope.

By the way, we already started to work on AutoYaST support, so stay tuned if you are one of those users missing this feature.

Open Discussion: Easy Way to Change Installer Settings

For quite some time, there has been a feature request to allow changing the installer settings at runtime. However, we are still unsure how it should look and which use cases we should cover.

The discussion is still ongoing, but we have opened a GitHub issue to discuss it further. So, if you feel you can help, feel free to join the conversation.

But That’s Not All

As usual, we have been working on many more things. So let’s select a few of them that you might find interesting:

What’s next?

We have just started the last sprint of 2020. We will slow down our work around our Cockpit modules because we feel that it is time to listen to others to decide what’s next. But we plan to work on many different things, like the storage layer, LibYUI, the installer reconfiguration feature… So if you are curious about what we can achieve during this sprint, let’s meet here in around two weeks.

the avatar of openSUSE News

Mojolicious, PHP, grep update in Tumbleweed

Half a dozen openSUSE Tumbleweed snapshots have been released since last week’s blog update for Geekos’ favorite rolling release.

Six packages were updated in the most recent 20201202 snapshot. An updated keyring was signed and obsolete documentation macros were removed in the update of mtools 4.0.26, which is a collection of utilities to access MS-DOS disks from GNU and Unix without mounting them. The timing and password encrypting/decrypting package python-scrypt updated to version 0.8.17 and added additional test vectors from Request for Comments. Another PyPI package python-atpublic updated from version 1.0 to version 2.1.1; the package dropped Python 3.4 and 3.5 and added Python 3.8 and 3.9. Someone was excited because the package also fixed the doctests to run and pass, which was highlighted with an exclamation point in the changelog - congrats. The other packages to update in the snapshot were fcitx-qt5 1.2.5, libmodulemd 2.10.0 and perl-Types-Serialiser 1.01.

The first snapshot to arrive this month was 20201201. Three YaST packages were updated; the update of yast2-installation 4.3.22 fixed the full media product selection during the setup. Fingerprint reader package fprintd provided proper hotplug support and authentication now requires a new print to enroll with the 1.90.4 version. Other packages to update in the snapshot were the gaming library for game controllers libmanette 0.2.6, libyui-qt-pkg 2.48.5 and the real-time web application framework perl-Mojolicious 8.66.

The 20201130 snapshot updated php 7.4.13, which brought several bug fixes including a fix for OpenSSL that had an OCB mode failure. The second update of the Linux Kernel came in the snapshot; the 5.9.11 kernel fixed the arm64 handling of the erratum 1418040 that had prevented a CPU from onlining. The universal messaging library zeromq updated to version 4.3.3 and fixed a Denial-of-Service Common Vulnerabilities and Exposures on CURVE/ZAP-protected servers by unauthenticated clients.

ImageMagick 7.0.10.43 arrived in the largest snapshot of the week - 20201129. The image creator, editor and modifier provided better support for TIFF YCbCr photometric and added support for the FilmLight FL32 image format. The bugfix release for GNOME updated several GNOME 3.38.2 packages including the personal management application evolution, calculator, control center, gnome-desktop, maps and gnome-music, which provided a fix for new songs retrieval when they are added and fixed a playlist sorting crash. Improvements were made to the user manual in the 3.38.1 gedit update. Another text editor, vim, fixed some popup failures in the 8.2.2039 update. Flatpak 1.8.3 made the in-memory summary cache more efficient and fixed an authentication error and authentications that were getting stuck in a loop. Other packages to update in the snapshot were autoyast2 4.3.63, dconf-editor 3.38.2, libostree 2020.8 and vala 0.50.2.

A new major version of Mozilla Firefox arrived in snapshot 20201127. Firefox 83.0 is getting faster and improves page load performance by up to 15 percent, page responsiveness by up to 12 percent, and reduced memory usage by up to 8 percent, according to the project’s release notes. Command-line utility grep 3.6 fixed the GREP_OPTIONS environment variable to no longer affect grep’s behavior. The jhbuild package, which is used to building collections of source packages, updated to version 3.38.0+3. Command line pdf converter qpdf fixed the handful of integer overflows in version 10.0.4 and libX11 bumped up from a 1.6 to 1.7 version because of new Application Programming Interfaces.

Snapshot 20201125, which arrived after last week’s blog was released, brought an update to the 3D graphics package Mesa 20.2.3, the 5.9.10 Linux Kernel, Node.js 14.15.1, Qt 5.15.2 and python-h2.

the avatar of Nathan Wolf
the avatar of Nathan Wolf

the avatar of openSUSE News

openSUSE Release Team to Share Results from arm Survey in Online Meetup

Members of the openSUSE release team members will share results of openSUSE on arm during two separate online sessions on openSUSE’s Jisti instance Dec. 2.

The first session will be at 10:00 UTC and the second session at 16:00 UTC. Both sessions are expected to cover the same content and reach different time zones globally for those interested in attending.

Overall, there were almost 300 responses submitted. The core team to develop the survey wants to use the results as a baseline for future surveys about arm to help gauge trends about development efforts with openSUSE on arm architecture.

The results did offer some telling answers about the majority of openSUSE use on arm. More than 4 out of 5 responses indicated they used AArch64, Raspberry Pi 3, Raspberry Pi 4, PinePhone and/or Pine64.

The most favored distribution was almost evenly split between openSUSE Tumbleweed and openSUSE Leap. Of those using openSUSE Leap, almost half stated they used Leap for the stability. Almost half also indicated they would be willing to migrate from Leap to openSUSE Tumbleweed if it was as good enough.

A majority of responses indicated they were using ARMv6, ARMv7, or ARMv8 less than a year.

The developers discussed the results today and made some interpretations from the data. One conclusion is that some people might not be aware that openSUSE Tumbleweed has AArch64 images on software.opensuse.org and that some video packages were important to be included in the images. Additionally, there were multiple comments about sound drivers for the Raspberry Pi 4 had not backported to Leap 15.2 and Tumbleweed, but those drivers are expected to arrive the 5.10 kernel, which is the current version of the Linux Kernel mainline.

The intent of the survey was to better understand the arm user base and to determine a path or ARMv7.

The release team wants to share the results about what they learned on the openSUSE Jisti meetup Dec. 2 at 10:00 UTC and at 16:00 UTC. Each session is scheduled for an hour.

the avatar of Robbi Nespu

Sending JSON data file using CURL to API endpoint

I developed warehouse system and use restful as communication method between our software and client software. We let end point of our system to talk each other with API designed.

For simple and small test using Postman or SOAP-UI is enough for me but to when to test this system with massive data via API is quite headache, plus the mock features on Postman limited and not “mocking” enough as I want.

Lucky enough, I am good with unit test (self claimed :satisfied:) so since the system are develop using java, then I use Junit as helper to help me do the automation test. It look nice when test it locally but somehow I still have an issue to remote test using Junit on my Eclipse IDE. It all because the remote server we connnecting is on customer premise and the connection are so bad! :triumph:

As a guy who love the old school trick, I use curl as the best and simple solution to POST the data into system API endpoint and I was right, the server much responsive to handle data.

Here I share how I using curl to POST data to our API endpoint locally (ssh to server and run the command inside). First of all, i will generated json file to use as data driven unit test and send to my server via scp:

$ scp /C/Users/Robbi/Desktop/TEST_CASE/*.json sayaComel@201.22.13.17:/tmp/test

when finished transfer the files, just ssh into server and navigate where the data are stored.

Let see, here I have 212,717 json file that I want this use with API endpoint. (Tips: All filename must are unique and properly sorted, so you can trace if you unit test failed)

$ find . -type f | wc -l
212717

How to POST json data file to API endpoint?

If I want to POST a single data from my file, I just need to send command like this from directory that store my data file:

$ curl -X POST -H "Content-Type: application/json"  -d @TC-00001.json  http://localhost:8182/order

If I want to POST all the data from my file, I simply just need to execute this looping command inside directory that store my data files:

$ for f in TC-*.json; do printf "\nLoad ${f} - " && curl -X POST -H "Content-Type: application/json" --data @${f} http://localhost:8182/order;done

Simple right? As long you can generate json file then you can use this technique todo data driven test your system endpoint :)

the avatar of openSUSE Mauritius