Nethserver-arpwatch: Needs Tests

Development Testing
1

Hi to all,

i need some tests on a new contribs: nethserver-arpwatch.

Before install it, keep in mind that this is my first try to do a contrib and also if this is a conversion of an existent sme contribs, please use only in a test environment. tnx :grin:

rpm: http://mirror.framassa.org/dz00test/nethserver-arpwatch-1.0.0-2.ns6.noarch.rpm
srpms: http://mirror.framassa.org/dz00test/nethserver-arpwatch-1.0.0-2.ns6.src.rpm
source: https://github.com/dz00te/nethserver-arpwatch

to install it:

yum install http://mirror.framassa.org/dz00test/nethserver-arpwatch-1.0.0-2.ns6.noarch.rpm

by default the service is enabled after installation, on all ethX in Green zone

some config:

to configure where to send the reports:

config setprop arpwatch mail mail@domain.com

default: root user of nethserver

to configure which interface enable:

config setprop arpwatch interface ethX

default: all eth on Green

to disable the service:

config setprop arpwatch status disabled

default enabled

after changes to apply the new config:

signal-event nethserver-arpwatch-save

to devs: considering that i’m using this package as training, feel free to tell me what i’ve done wrong, tnx :wink:

6 Likes
2

Great news @dz00te!

I hope you’ll send me your public ssh key so you can upload your RPM on NethForge, too (packages.nethserver.org)!

3

I’ll try it as soon as possible :+1:

4

some enhancements like that you will find all interfaces with a green role…IMHO the status propriety should be enabled by default

# -u <username> : defines with what user id arpwatch should run
# -e <email>    : the <email> where to send the reports
# -s <from>     : the <from>-address
{
 use esmith::NetworksDB;
 my $ndb = esmith::NetworksDB->open_ro();

my $bogonset='';
my $bogon = ${'arpwatch'}{'bogon'};

if ($bogon eq 'enabled') {
 $bogonset = '';
}
else {
 $bogonset = '-N';
}

my $mailset= ${'arpwatch'}{'email'};
foreach my $i ($ndb->green) {
    my $interfaces = $i->key;
    $OUT .= "OPTIONS=\"-i $interfaces  $bogonset -f /var/lib/arpwatch/arp.dat -u arpwatch -e $mailset -s 'arpwatch\@${'DomainName'}'\"\n";
}
}
2 Likes
5

yes, i will… but i can’t attach within discourse pm, it’s ok if i copy/paste it in a pm?
btw i didn’t see nethforge-testing folder for 6.7 on mirror it’s correct?

6

thank you steph, i agree with you the status should be enabled by default (btw thanks for the code to identify the green net )… but as i say i’m using it as training, i’ll try to explain my intention:
i’ve added some property like email and interface, because i would also try to make (in a long time :slight_smile: ) the gui to change config for email and interface, and also it would be nice to see the status table of arpwatch.
Now, to do this i was thinking to identify the green net only when installing package, and populate the interface property, to start correctly the service. So if i understood correctly i can’t do this in template.
Yesterday, i’ve found this http://www.nethserver.org/dokuwiki/doku.php?id=spec_file_notes on the brand new wiki :slight_smile: (as always tnx for that) … maybe i could use the %post of specfile to achieve this… it is correct or there is a better way?
tnx

7

There should not be any problem to publish a public key but a PM here or an email to davide.principi(AT)nethesis.it is ok for me.

Edit: GitHub provides an API to fetch any user’s public key

Yes, -testing repos are not sent to mirrors. I hope this choice eases the QA process by removing the synchronization lag.

8

ok that could be a good new training but keep in mind the KISS mode, all need to be workable out of the box…no manual actions needed.

of course that could be done in a template : esmith:db [Stephdl Repository]

the problem of identify the nic only when you install the rpm is not satisfying, because you must think the case where the sysadmin will swap his nics…look after the network event and expand your template with this event.

for now go to documentation [Stephdl Repository] you have more stuffs to read…concerning the %post you shouldn’t use it…the %pre is different, sometime you must create an user before to install the rpm.

If you want to expand a template only for the installation, you should create two events

nethserver-myrpm-update → expanded by the rpm installation
nethserver-myrpm-save → expanded by the admin in the terminal or in the GUI, this event doesn’t expand the template

you are welcome

2 Likes
9

Looks interesting, we should have a dev team which help you to test such packages and gather feedback :smile:
@giacomo, @davidep, @filippo_carletti, @alep, @stephdl, @Stll0

10

I did a little code review and it’s almost good!

I agree with Stephan on interface property, it should be a comma-separated list of roles.
The template can than expand the role into interfaces names (but I don’t know how arpwatch deals with multiple interfaces).
If you set the default value of interface property to green, you can leave the daemon enabled by default.

Last, the template fragment /etc/e-smith/templates/etc/sysconfig/arpwatch/ALL should be renamed to /etc/e-smith/templates/etc/sysconfig/arpwatch/10base, but this is not mandatory, it’s only a best practice.

2 Likes
11

I have the answer, arpwatch can use only one nic at the same time, except if you launch one deamon instance for each NIC, see Everything about nothing: arpwatch on multiple interfaces
But the init.d script must be customised and become a new template if you want to keep it after an upgrade.

The same solution has been found by debian for the same purpose.

@dz00te don’t be hidden…we wish only the best for you :slight_smile:

2 Likes
12

wow lot of useful info here tnx @stephdl @giacomo @davidep …
unluckily i did not have (and i will not have) much time this week and considering that i’m not a dev i really need lot of time :slight_smile:
but i’ve done some tests based on first infos steph gave me, and it works correctly with only one eth, then i’ve tried with multiple green and after some tests i’ve found the same link posted above to have the daemon working on multiple eth … then my son wakes up and no more perl or rpm :wink:
So considering that this is a training i was thinking that maybe the correct way to proceed could be (ordered by increasing difficulty):

  1. do the correction to package implementing yours advice, to have arpwatch
  • Started after install
  • Configured on first green ethx found
  • Use nethserver-arpwatch-update and nethserver-arpwatch-save

  1. implement a script to update ethercodes.dat using Sanitized IEEE OUI Date (oui.txt) (or put it in the file to separate rpm, or … honestly i’m not sure at the moment how to do but i would like to have it updated :))

  2. try to implement arpwatch for multiple eth (with multiple arp.dat, with a customized init script), the idea is to have at the end the opportunity to select for role or for single eth

  3. a gui (???) if i will ever complete points 2 and 3 :slight_smile:

do you think it could be a good work path, while trying to learn something?

i’m sorry to have posted a incomplete version and i’m a little bit ashamed to do so basic questions, but i’ve done most of this one month ago, and the idea was that putting it on the public forum could help me to don’t forgive the study of perl/nethserver…
i hope to post soon an update to close the point 1… tnx again

2 Likes
13

Don’t say sorry, we’re all here to learn from others. :fishing_pole_and_fish:

14

You are a padawan developer, the way is sometime much more longer than we would

1 Like
15

@dz00te these are you and @stephdl on your shoulders

2 Likes
16

This rpm comes from SME Server which was supposed to have only one Internal NIC, therefore the rpm was not intended to find which NIC has a green role, but NethServer lets a lot of freedom on the choices of your network. IMHO the rpm needs to be adapted to this case of configuration, and we must implement the multiple NIC case (one deamon and one arp-etX.dat file for each NIC).

A fallback choice should be to propose the rpm like you did and let the sysadmin decide which unique NIC is monitored.

From my point of view, the gui is really not a mandatory, this rpm is aimed to be to the destination of sysadmin who have the need to keep informations about IP/Mac which are connected to their local network, but of course, since it is said, someone will come with this need :smile:

With smeserver-geoip we have the same issue, the geoip database needs to be updated sometime, by a cron each month, and following the installation.

1 Like
17

finally today i’ve had some hours to dedicate to code (well, to try to code :grin: )
i think i’ve solved how to find multiple eth on green and generate correct config, and tested with the customized init.d script it works… what is not clear to me is this part:

do you know where i can find some info or some examples in other contribs, or have any hints in how overwrite the init.d script?

tnx

1 Like
18

simply make a new template of the initscript, I mean this

/etc/e-smith/template/etc/rc.d/init.d/arpwatch/10base

then of course expand it with nethserver-arpwatch-{update,save}

you will need probably to set owner ship and permisions : Templates — NethServer 7 documentation

create a file /etc/e-smith/template.metadata/etc/rc.d/init.d/arpwatch with the relevant content
for example

 UID="root"
GID="root"
PERMS=0755
1 Like
19

Another solution could be to create an upstart job, see /etc/e-smith/templates.metadata/etc/init/httpd-admin.conf for example.

If I recall well the documentation the upstart init script has the priority against a sysvinit script,so it is used first…but I have not played with upstart script so I have no example with my modules I can point you as examples.

1 Like
20

I am interested in how this is going :point_up_2: