Thread Info
  • State Not Answered
  • Replies 18 replies
  • Subscribers 5 subscribers
  • Views 4684 views
  • Users 0 members are here
Options
Suggested

Using EAP Refresh 1 ISO to build a test XG

rfcat_vk

I have sent using a J1900 based box for various varsions of XG. So I decided to move the MR-9 to my E# box and use the J1900 as the EAP test box.

In summary a very painful exercise.

The EAP ISO has a new install process or at least the startup screen shows the SFLoader starting first, then you are offered 18.0.0.113 install with the standard question Y to install. All going well, takes awhile and when you get to the end the remove install software and enter y to reboot.

Nothing appears to be happening after the screen is cleared and a message booting 18.0.0.113 appears. Waited awhile, restarted the XG, again same screen, disk activity, buy no screen updates. Waited longer this time and console appears requesting password, this is good. Check various settings including setting the time. Tried logging in to the GUI, no success, waited, checked W10n for address assignment, it ha a valid address, but no connection.  Restart again, but no access. 

So a fresh install, same process as above, but this time waited longer (no screen activity) and eventually I was able to login to the GUI with finish install screen. Go through the normal steps and add XG device ID which synchronises but doesn't go any further. So restart browser, no joy. Restart XG and wait even longer, login via GUI and found installation is completed. What the heck?

Bugs,

GUI - insights doesn't't update even overnight

Notifications - goes fine until I change the state of the management port, then the circle of busy. Refresh browser and can use other GUI tabs. Check the notification page, still spinning. Restart XG, notification page still spinning. After initial use console does not respond until the XG is restarted.

I decide the J1900 is just too slow to make any changes or look at various logs.

Time to use a bigger box based on an e3-1240 v3. Way faster, but even less information during installation because the build software does not cooer to known how to configure a display card. 

Another install this time watching disk lights and the CD drive, guessed at answers based on previous installation experience. waited a short time until the NIC lights started flashing and logged into the GUI to be presented with the finish install screen. Same process as the J1900 installations but way faster.

Changed some of the notifications during the finish screen process because there were more screens presented.

Restarted and was able to login to see the normal XG GUI. Change a couple of rules and change MTA to legacy. Then tried to up date notifications and again the perpetual ball of busy.

 

Observations

1/. default MTA configuration and firewall rule appears to leave the XG open as a mail relay. Lots of failed relay attempts logged.

2/. Install process does not appear to have been checked very thoroughly

3/. something wrong with the console setup during installation

4/. No default video drivers provided in the ISO.

 

E3-1240 runs rings around J1900 for management. Both performed well for the speed test on my 50/20 data service

Yes, I know a long rant.

Ian

Parents
  • 0

    I haven't installed XG since v17 so the process seemed fairly straight forward to me atleast in a vm. My load average was a little higher in the beginning but calmed down nicely after the first few minutes and have been fairly stable since. The firewall is snappy compared to my memory of it with v17. Only thing that has gone up is the memory footprint. Of course I am not running a 100 DPI rules and relying mostly on web proxy without ssl decryption so essentially it is v17 and that could be the main difference.

    I did notice the allow all smtp firewall rule but as everything else XG, allow all doesn't mean it will pass any traffic unless configured so nothing to worry about other than people trying and trying to use it as a relay. But I do agree with your sentiment and deleted that rule immediately upon installation.

    Regards.

    Edit: My firewall did reboot on its own under heavy load with 4GB allocated in a vm and that was strange as I haven't had a spontaneous reboot of any OS in years without hardware problems.

Reply
  • 0

    I haven't installed XG since v17 so the process seemed fairly straight forward to me atleast in a vm. My load average was a little higher in the beginning but calmed down nicely after the first few minutes and have been fairly stable since. The firewall is snappy compared to my memory of it with v17. Only thing that has gone up is the memory footprint. Of course I am not running a 100 DPI rules and relying mostly on web proxy without ssl decryption so essentially it is v17 and that could be the main difference.

    I did notice the allow all smtp firewall rule but as everything else XG, allow all doesn't mean it will pass any traffic unless configured so nothing to worry about other than people trying and trying to use it as a relay. But I do agree with your sentiment and deleted that rule immediately upon installation.

    Regards.

    Edit: My firewall did reboot on its own under heavy load with 4GB allocated in a vm and that was strange as I haven't had a spontaneous reboot of any OS in years without hardware problems.

Children
No Data
Unfiltered HTML